home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Fritz: All Fritz
/
All Fritz.zip
/
All Fritz
/
DEMO
/
FRACT
/
FRACTINT.DOC
< prev
next >
Wrap
Text File
|
1990-05-26
|
175KB
|
3,737 lines
Fractint Version 13.0r
NOTE: version 13.0r is just version 13.0 re-compiled under Microsoft C
version 5.1 (13.0 was compiled under MSC 6.0). When compiled under MSC 6.0,
the 'type=formula' code is partially broken (selecting the 'tetrate'
formula, for example, hangs your PC). There is no corresponding 13.0r
source-code release, because the source code hasn't changed.
*************************************************************************
* WARNING WARNING WARNING *
* >> F1, not 'h', is now the HELP key!!! << *
* For Help at any time, press the F1 key *
* For EGA 320x200x16 video mode, press the F9 (not F1) key *
* For EGA 640x200x16 video mode, press the CF4 (not F9) key *
*************************************************************************
CONTENTS
New Features in Version 13.0
Introduction
1. Quick Start: FRACTINT Commands
Plotting
Colors
Saving, Restoring and Printing
"3D"
Hints
2. Fractal Types
Mandelbrot
Julia
Newton's Formula
Lambda
Plasma Clouds
Lambda/Sine, Cosine, Sinh, Cosh, Exponent
Mandel/Sine, Cosine, Sinh, Cosh, Exponent
Barnsley Mandelbrot/Julia
Barnsley IFS
Sierpinski Gasket
Quartic Mandelbrot/Julia
Distance Estimator Mandelbrot/Julia
Pickover Mandelbrot/Julia Types
Peterson Variations
Unity
Bifurcation
Lorenz, Lorenz3d
Rossler
Henon
Pickover
Gingerbreadman
Test Stub
Formula
Julibrots
Diffusion
Doodads, Bells and Whistles
"3D" Images
Inversion
Decomposition
Starmaps
Logarithmic Palettes
Pickover Biomorphs and Popcorn
3. Command-Line Arguments, Batch Mode, and SSTOOLS.INI
4. File Formats, Colors, and All That
.FRA and .GIF Files
Continuous Potential
Palette Maps
5. Hardware Support
Notes on Modes, "Standard" and Otherwise
FRACTINT.CFG
6. Fractals and the PC
A Little History
B.M. (Before Mandelbrot)
Who Is This Guy, Anyway?
A Little Code
Logic Speed-ups
The Limitations of Integer Math
The Fractint "Fractal Engine" Architecture
Appendix A: Mathematics of the Fractal Types
Appendix B: Stone Soup with Pixels
Appendix C: Revision History
Appendix D: Bibliography
Appendix E: Other Recommended Fractal Programs
NEW FEATURES IN VERSION 13.0
F1 is now the HELP KEY!!!
Use F1 for help
Use F9 for EGA 320x200x16 video mode
Use CF4 for EGA 640x200x16 mode (if anybody uses that mode)
Speed!! More speed!! We've gotten faster!!
Super-Solid-guessing (three or more passes) from Pieter Branderhorst
(replaces the old solid-guessing mode)
New Boundary Tracing option from David Guenther
("fractint passes=btm", or use the new 'x' options screen)
New "outside=nnn" option sets all points not "inside" the fractal
to color "nnn" (and generates a two-color image).
New 'x' option from the main menu brings up a full-screen menu of many
popular options and toggle switches
New "Speed Key" feature for fractal type selection (either use the
cursor keys for point-and-shoot, or just start typing the name of
your favorite fractal type)
New "Attractor" fractals (Henon, Rossler, Pickover, Gingerbread)
New diffusion fractal type by Adrian Mariano
New "type=formula" formulas from Scott Taylor and Lee H. Skinner.
New "sound=" options for attractor fractals
Sound=x plays speaker tones according to the 'x' attractor value
Sound=y plays speaker tones according to the 'y' attractor value
Sound=z plays speaker tones according to the 'z' attractor value
(These options are best invoked with the floating-point algorithm
flag set.)
New "hertz=" option for adjusting the "sound=x/y/z" output.
Printer support for color printers (printer=color) from Kurt Sowa
New video modes:
Trident 4000 and Oak Technologies SuperVGA support from John Bridges
Improved 8514/A support (the zoom-box keeps up with the cursor keys now!)
Tandy 1000 640x200x16 mode from Brian Corbino (which does not, as yet,
work with the F1(help) and TAB functions)
The Julibrot fractal type and the Starmap option now automatically
verify that they have been selected with a 256-color palette, and
search for, and use, the appropriate GLASSESn.MAP or ALTERN.MAP
palette map when invoked. *You* were supposed to be doing that
manually all along, but *you* probably never read the docs, huh?
Bug Fixes for Version 12.0:
TAB key now works after R(estore) commands
PS/2 Model 30 (MCGA) adapters should be able to select 320x200x256
mode again (we think)
Everex video adapters should work with the Autodetect modes again
(we think)
INTRODUCTION
FRACTINT plots and manipulates images of "objects" -- actually, sets of
mathematical points -- that have fractal dimension. See chapter 6 for
some historical and mathematical background on fractal geometry, a
discipline named and popularized by mathematician Benoit Mandelbrot.
For now, these sets of points have three important properties:
1) They are generated by relatively simple calculations repeated over
and over, feeding the results of each step back into the next --
something computers can do very rapidly.
2) They are, quite literally, infinitely complex: they reveal more and
more detail without limit as you plot smaller and smaller areas.
FRACTINT lets you "zoom in" by positioning a small box and hitting
<Enter> to redraw the boxed area at full-screen size; its maximum
linear "magnification" is over a trillionfold.
3) They can be astonishingly beautiful, especially using PC color
displays' ability to assign colors to selected points, and (with VGA
displays or EGA in 640x350x16 mode) to "animate" the images by quickly
shifting those color assignments.
The name FRACTINT was chosen because the program generates many of its
images using INTeger math, rather than the floating-point calculations
used by most such programs. That means that you don't need a math co-
processor chip (aka floating-point unit or FPU), although for a few
fractal types where floating-point math is faster, the program recog-
nizes and automatically uses an 80x87 chip if it's present. It's even
faster on systems using Intel's 80386 and 80486 microprocessors, where
the integer math can be executed in their native 32-bit mode.
FRACTINT works with many adapters and graphics modes from CGA to the
1024x768, 256-color 8514/A mode. Even "larger" images, up to
2048x2048x256, can be plotted to RAM, EMS, or disk: this bypasses the
screen and allows you to create images with higher resolution than your
current display can handle, and to run in "background" under multi-
tasking control programs such as DESQview.
FRACTINT is an experiment in collaboration. Many volunteers have joined
Bert Tyler, the program's first author, in improving successive ver-
sions. Through electronic-mail messages, first on CompuServe's PICS forum
and now on COMART, new versions are hacked out and debugged a little
at a time. FRACTINT was born fast, and none of us has seen any other fractal
plotter close to the present version for speed, versatility, and all-
around wonderfulness. (If you have, tell us so we can steal somebody
else's ideas instead of each other's.) See Appendix B for information
about the authors and how to contribute your own ideas and code.
The executable FRACTINT.EXE is public domain, and we encourage you to
share copies and upload it to bulletin-board systems. Except for those
modules marked with a copyright notice (and subject to the authors'
conditions in the notices), the source code is also public domain.
There is no warranty of its suitability for any purpose, nor any
acceptance of liability, express or implied.
Contribution policy: Don't want money. Got money. Want admiration.
1. QUICK START: FRACTINT Commands
To start the program, enter FRACTINT at the DOS prompt. The program
displays an initial "credits" screen, and waits for you to hit a
command key that will (1) start plotting in a specific video mode or
(2) set one of many options. You can also (at this screen or at any
time) press a HELP key (<H> or <?>) for screens describing the commands
and video modes. As soon as you select a video mode, the program begins
drawing an initial display -- the "full" Mandelbrot set, if you haven't
selected another fractal type. From this point on, and AT ANY TIME, you
can hit any of the following keys to select a function. (For the
"typewriter" keys, upper and lower case are equivalent: <B> and <b>,
<?> and </>, have the same result.)
Many commands and parameters can be passed to FRACTINT.EXE as command-
line arguments or read from a configuration file; see Sec. 3 for
details.
Plotting Commands
<F1> or <?>
Bring up a help screen. The Escape key brings you back.
Function keys & various combinations (see help screens)
Select the corresponding video mode and redraw the screen
<Page Up>
Display and shrink the zoom box ("zoom in"). The LEFT button of a mouse
displays the box; push the mouse away from you while holding that
button down to shrink the box.
<Page Down>
Display and expand the zoom box ("zoom out"). Pulling the mouse towards
you with the left button down has the same effect.
Cursor ("arrow") keys
Move ("pan") the zoom box. Moving the mouse has the same effect. With
an enhanced-keyboard BIOS, <Control> plus a cursor key moves the box 5
times faster. With a mouse, the RIGHT button controls fast vs. slow
panning.
<Enter> ("Return") or <End>
Redraw the area inside the zoom box as a full-screen image. Or press
BOTH mouse buttons. (If there is no zoom box, this just re-draws the
current screen.)
<Control><Enter>
"Zoom out," so that your screen would fill the current zoom box, and
redraw.
<Home>
Redraw the previous image. The program tracks 50 sets of coordinates.
<Tab>
Display the current fractal type, parameters, screen or (if displayed)
zoom-box coordinates, maximum iteration count, and other information
useful in keeping track of where you are. With version 12.0, the Tab
function is non-destructive - if you press it while in the midst of
generating an image, you will continue generating it when you return.
The Tab function now also tells you if your image is still being
generated or has finished - a handy feature for those overnight,
1024x768 resolution fractal images.
<Spacebar>
Toggle between Mandelbrot-set images and their corresponding Julia-set
images. Read the notes in Sec. 2 before trying this option if you want
to see anything interesting.
< or >
Lower or raise the maximum iteration count (the number of times the
program carries out its basic calculation before assigning colors). See
Sec. 2. (Note: the maximum iteration count can now also be selected
explicitly using the "X" options screen.)
<1>, <2>, or <G>
Select single-pass, dual-pass, or solid-guessing (default) mode, then
redraw the screen. Single-pass mode draws the screen pixel by pixel.
Dual-pass generates a "coarse" screen first as a preview using 2x2-
pixel boxes, and then generates the rest of the dots with a second
pass. Solid-guessing performs from two to four visible passes - more
passes in higher resolution video modes. Its first visible pass is
actually two passes - one pixel per 4x4, 8x8, or 16x16 pixel box
(depending on number of passes) is generated, and the guessing logic
is applied to fill in the blocks at the next level (2x2, 4x4, or 8x8).
Subsequent passes fill in the display at the next finer resolution,
skipping blocks which are surrounded by the same color. Solid-guessing
can guess wrong, but it sure guesses quickly! Note: these options,
along with the Boundary-Tracing alternative, can now also be selected
using the "X" options screen. Boundary Tracing, which only works
with fractal types (such as the Mandelbrot set, but not the Newton
type) that do not contain "islands" of colors, finds a color "boundary",
traces it around the screen, and then "blits" in the color over the
enclosed area.
<B>
Create a batch file, FRABATCH.BAT, that will start FRACTINT with the
command-line arguments needed to draw the current image. If
FRABATCH.BAT already exists, a new line is appended to it.
<T>
Select a fractal type. Move the cursor to your choice and hit <Enter>.
You will be prompted for any parameters that type may require.
<X>
Select any number of eXtended options. Brings up a full-screen menu of
options, any number of which you can change at will. This list currently
includes the F(loating point algorithm) toggle, the image generation
algorithm (passes = 1, 2, solid-guessing, or boundary tracing), the
"maxiter=" iteration maximum, the "inside=" and "outside=" colors, the
Logarithmic Palettes option, the Biomorph and Decomposition
algorithms, the "sound=" option, and the "warn=" option.
<E>
Call up an editor that modifies, saves and restores various parameters.
Currently you can change the coefficients used in plotting the Barnsley
IFS fractal types or the 3D transformations used with the "Lorenz3D"
and "IFS3D" fractal types, including the selection of "funny glasses"
red/blue 3D.
<F>
Toggles the use of floating-point algorithms. Their use is shown on the
<Tab> status screen. (Note: the floating point algorithms option can
now also be turned on and off using the "X" options screen.)
<I>
Apply the inversion process (Sec. 3) and redraw the screen. Not appli-
cable to all fractal types.
<N> or <L>
Select normal (the default) or logarithmic palette mapping and redraw
the screen. (See Sec. 3 for details.) (Note: the Logarithmic palette
option can now also be turned on and off using the "X" options screen.)
<Q>
Apply the quaternary or binary decomposition coloring scheme (see Sec.
3) and redraw the screen. Not applicable to all fractal types.
(Note that the decomposition scheme can now select 8, 16, 32, 64, 128,
and 256-way decomposition, but we're stuck with <Q> for Quaternary.)
(Note: the Decomposition option can now also be turned on and off
using the "X" options screen.)
<O> (the letter, not the number)
If pressed while an image is being generated, toggle the display of
intermediate results -- the "orbits" FRACTINT uses as it calculates
values for each point. Slows the display a bit, but shows you how
clever the program is being behind the scenes. (See "A Little Code" in
Sec. 6.)
<Insert>
Restart at the "credits" screen
<D>
Shell to DOS. Return to FRACTINT by entering "exit" at a DOS prompt.
<Esc> or <Delete>
Exit FRACTINT and return to DOS.
Color Commands
The color-cycling commands are available ONLY for VGA adapters and EGA
adapters in 640x350x16 mode. Some keys have different functions specif-
ic to this mode.
Note that the palette colors available on an EGA adapter (16 colors at
a time out of a palette of 64) are limited compared to those of VGA,
super-VGA, and MCGA (16 or 256 colors at a time out of a palette of
262,144). So color-cycling in general looks a LOT better in the latter
modes. Also, because of the EGA palette restrictions, some commands are
not available with EGA adapters.
<+> or <->
Switch to color-command mode and begin cycling the palette by shifting
each color to the next "contour."
<C>
Switch to color-command mode but do not start cycling. The normally
black "overscan" border of the screen changes to white as a reminder
that you are in this command mode.
<H> or <?>
Bring up a HELP screen with commands specific to color command mode.
ESCAPE exits.
<+> or cursor->, <-> or cursor<-
Reverse the cycling direction "out" or "in."
Cursor up/down
Increase/decrease the cycling speed. High speeds may cause a harmless
flicker at the top of the screen.
<F2> through <F10>
Switches from simple rotation to color selection using randomly-gener-
ated color bands of short (F2) to long (F10) duration.
<1> through <9>
Causes the screen to be updated every 'n' color cycles (the default is
1). Handy for slower computers.
<Enter>
Randomly selects a function key (F2 through F10) and then updates ALL
the screen colors prior to displaying them for instant, random colors.
Hit this over and over again (we do).
<Spacebar>
Pause cycling with white overscan area. Cycling restarts with any
command key (including another spacebar) -- or you can use any non-
command key to exit color-command mode so you can (S)ave the image.
<Shift><F1>-<F10>
Pause cycling and reset the palette to a preset two-color "straight"
assignment, such as a spread from black to white. (Not for EGA)
<Ctrl><F1>-<F10>
Pause and use a two-color cyclical assignment, e.g. red->yellow->red
(not for EGA).
<Alt><F1>-<F10>
Pause and use a 3-color cyclical assignment, e.g. green->white->blue
(not for EGA).
<R>, <G>, <B>
Pause and increase the red, green, or blue component of all colors by a
small amount (not for EGA). Note the case distinction of this vs:
<r>, <g>, <b>
Pause and decrease the red, green, or blue component of all colors by a
small amount (not for EGA).
<D> or <A>
Pause and load an external color map from the files DEFAULT.MAP or
ALTERN.MAP, supplied with the program.
<M>
Pause and prompt for the filename of an external color map. Several
others are supplied with the program. (The .MAP extension is assumed;
see Sec. 4 for details on creating your own map files.)
<S>
Pause, prompt for a filename, and save the current palette to the named
file (.MAP assumed).
<X>
Enters the "Cross-Hair" Palette manipulation sub-mode, described below,
in which you can modify your image one color (palette) at a time
(not for EGA).
Any other key terminates the color-cycling process (you can always
return to it with another <C>, <+> or <->) and returns to the main
command mode.
Cross-Hair Mode (a Sub-Mode of Color-Cycling)
This mode is entered from the main color-cycling mode by pressing the
"X" key, which brings up a "Cross-Hair" cursor with which you point
to a pixel using the particular color palette you wish to modify.
Unlike the main color-cycling level, where you are modifying all of the
colors at once, Cross-Hair mode modifies only one palette at a time.
This feature is currently available only on VGA adapters.
<Cursor ("arrow") Keys>
Move the cross-hair cursor around the screen. The Control-Cursor keys
move the cursor around faster. A mouse can also be used to move around,
in which case holding down the right button slows down cursor movement.
The palette value of the pixel in the middle of your cross-hair cursor
is the palette value that you will be manipulating.
<R>, <G>, <B>
Increase the red, green, or blue component of your palette color by a
small amount. Note the case distinction of this vs:
<r>, <g>, <b>
Decrease the red, green, or blue component of your palette color by a
small amount.
<+>, <->
Changes the RGB components of the palette you are pointing at to those
of the next higher (or lower, for the <-> key) palette value. Useful for
"erasing" bands of color.
<Page Up>, <Page Down>
Change the palette value of the cross-hair cursor to the next higher (or
lower) palette value. A handy feature when the cross-hair cursor gets
"lost" in the background. Holding down the left mouse button and moving
the mouse forward and backward has the same effect.
<ENTER>
Does nothing at all. Added only to prevent you from accidentally
exiting cross-hair mode by pressing both mouse buttons.
Any other key terminates Cross-Hair sub-mode and returns to the main
Color-Cycling command mode.
Save/Restore/Print Commands
<S>
Save the screen contents to disk. Progress is marked by colored lines
moving down the screen's edges. The default filename is FRACT001.FRA;
multiple saves in a session are automatically incremented 002, 003...
If you have files left over from previous sessions and want the program
to keep incrementing rather than starting at 001 again and overwriting,
see Sec. 3 for the "WARN=yes" argument (or set it with the "X" option
screen).
<R>
Restore an image previously saved with <S>, or a .GIF image (See Sec.
4). You are prompted for the filename, .FRA assumed.
<P>
Print the current fractal image on your (Laserjet or Epson-compatible)
printer. See Sec. 3 for how to let FRACTINT know about your printer
setup.
"3D" Commands
<3>
Restore a saved image as a 3D "landscape", translating its color
information into "height". You will be prompted for all KINDS of
options; see "3D Images" in Sec. 3 for details.
<O>
Restore in 3D and overlay the result on the current screen. (This
only works when there's a completed on screen, so it can't be
confused with the <O>-for-orbits toggle that ONLY operates WHILE a
fractal is being generated.)
HINTS
Remember, you do NOT have to wait for the program to finish a full
screen display before entering a command. If you see an interesting
spot you want to zoom in on while the screen is half-done, don't wait -
- do it! If you think after seeing the first few lines that another
video mode would look better, go ahead -- FRACTINT will shift modes and
start the re-draw at once. When it finishes a display, it beeps and
waits for your next command.
In general, the most interesting areas are the "border" areas where the
colors are changing rapidly. Zoom in on them for the best results. The
first Mandelbrot-set (default) fractal image has a large, solid-colored
interior that is the slowest to display; there's nothing to be seen by
zooming there.
Plotting time is directly proportional to the number of pixels in a
screen, and hence increases with the resolution of the video mode.
After you get used to the first "zoom levels," you may want to start in
a low-resolution mode for quick progress, and switch to a higher-
resolution mode when things get interesting. Plotting time also varies
with the maximum iteration setting, the fractal type, and your choice
of drawing mode. Solid-guessing (the default) is fastest, but it can be
wrong: perfectionists will want to use dual-pass mode (its first-pass
preview is handy if you might zoom pre-emptively) or single-pass mode.
When you start systematically exploring, you can save time (and hey,
every little bit helps -- these "objects" are INFINITE, remember!) by
<S>aving your last screen in a session to a file, and then going
straight to it the next time with FRACTINT FRACTxxx (the .FRA
extension is assumed). Or you could simply hit <B> to create a batch
file with the "recipe" for a given image, and next time start with
FRABATCH to re-plot it. See Sec. 4 for more on batch mode and the
command-line arguments the <B> command writes.
2. FRACTAL TYPES
This section is intended only as a quick introduction to the types;
more detail on the mathematics of types other than the Mandelbrot set
can be found in Appendix A, and some notes on how FRACTINT calculates
them in Sec. 6.
FRACTINT starts by default with the Mandelbrot set. You can change that
by firing it up with the command-line argument "TYPE=" followed by one
of the names in parentheses below, or within the program by hitting <T>
and typing in the name. If parameters are needed, you will be prompted
for them.
In the text that follows, due to the limitations of the ASCII character
set, "a*b" means "a times b", and "a^b" means "a to the power b".
THE MANDELBROT SET
This set is the classic: the only one implemented in many plotting
programs, and the source of most of the printed fractal images pub-
lished in recent years. Like most of the other types in FRACTINT, it is
simply a graph: the x (horizontal) and y (vertical) coordinate axes
represent ranges of two independent quantities, with various colors
used to symbolize levels of a third quantity which depends on the first
two. So far, so good: basic analytic geometry.
Now things get a bit hairier. The x axis is ordinary, vanilla real
numbers. The y axis is an imaginary number, i.e. a real number times i,
where i is the square root of -1. Every point on the plane -- in this
case, your PC's display screen -- represents a complex number of the
form:
x-coordinate + i * y-coordinate
If your math training stopped before you got to imaginary and complex
numbers, this is not the place to catch up. Suffice it to say that they
are just as "real" as the numbers you count fingers with (they're used
every day by electrical engineers) and they can undergo the same kinds
of algebraic operations.
OK, now pick any complex number -- any point on the complex plane --
and call it C, a constant. Pick another, this time one which can vary,
and call it Z. Starting with Z=0 (i.e., at the origin, where the real
and imaginary axes cross), calculate the value of the expression
Z^2 + C
Take the result, make it the new value of the variable Z, and calculate
again. Take that result, make it Z, and do it again, and so on: in
mathematical terms, iterate the function Z(n+1) = Z(n)^2 + C. For
certain values of C, the result "levels off" after a while. For all
others, it grows without limit. The Mandelbrot set you see at the start
-- the solid-colored lake (blue by default), the blue circles sprouting
from it, and indeed every point of that color -- is the set of all
points C for which the value of Z is less than 2 after 150 iterations
(default setting). All the surrounding "contours" of other colors
represent points for which Z exceeds 2 after 149 iterations (the
contour closest to the M-set itself), 148 iterations, (the next one
out), and so on.
Some features of interest:
1. Use the > key to increase the number of iterations. Notice that the
boundary of the M-set becomes more and more convoluted (the technical
terms are "wiggly," "squiggly," and "utterly bizarre") as the Z-values
for points that were still within the set after 150 iterations turn out
to exceed 2 after 200, 500, or 1200. In fact, it can be proven that the
true boundary is infinitely long: detail without limit.
2. Although there appear to be isolated "islands" of blue, zoom in --
that is, plot for a smaller range of coordinates to show more detail --
and you'll see that there are fine "causeways" of blue connecting them
to the main set. As you zoomed, smaller islands became visible; the
same is true for them. In fact, there are no isolated points in the M-
set: it is "connected" in a strict mathematical sense.
3. The upper and lower halves of the first image are symmetric (a fact
that FRACTINT makes use of here and in some other fractal types to
speed plotting). But notice that the same general features --lobed
discs, spirals, starbursts -- tend to repeat themselves
(although never exactly) at smaller and smaller scales, so that it can
be impossible to judge by eye the scale of a given image.
4. In a sense, the contour colors are window-dressing: mathematically,
it is the properties of the M-set itself that are interesting, and no
information about it would be lost if all points outside the set were
assigned the same color. If you're a serious, no-nonsense type, you may
want to cycle the colors just once to see the kind of silliness that
other people enjoy, and then never do it again. Go ahead. Just once,
now. We trust you.
JULIA SETS
These sets were named for mathematician Gaston Julia, and can be
generated by a simple change in the iteration process described above.
Start with a specified value of C, "C-real + i * C-imaginary"; use as
the initial value of Z "x-coordinate + i * y-coordinate"; and repeat
the same iteration, Z(n+1) = Z(n)^2 + C.
There is a Julia set corresponding to every point on the complex
plane -- an infinite number of Julia sets. But the most visually
interesting tend to be found for the same C values where the M-set
image is busiest, i.e. points just outside the boundary. Go too far
inside, and the corresponding Julia set is a circle; go too far out-
side, and it breaks up into scattered points. In fact, all Julia sets
for C within the M-set share the "connected" property of the M-set, and
all those for C outside lack it.
FRACTINT's spacebar toggle lets you "flip" between any view of the M-
set and the Julia set for the point C at the center of that screen. You
can then toggle back, or zoom your way into the Julia set for a while
and then return to the M-set. So if the infinite complexity of the M-
set palls, remember: each of its infinite points opens up a whole new
Julia set.
Historically, the Julia sets came first: it was while looking at the M-
set as an "index" of all the Julia sets' origins that Mandelbrot
noticed its properties.
NOTE: if you use the "PARAMS=" argument to warp the M-set by starting
with an initial value of Z other than 0, the M-set/J-sets correspon-
dence breaks down and the spacebar toggle no longer works.
NEWTON DOMAINS OF ATTRACTION (type=newtbasin)
The Newton formula is an algorithm used to find the roots of polynomial
equations by successive "guesses" that converge on the correct value as
you feed the results of each approximation back into the formula. It
works very well -- unless you are unlucky enough to pick a value that
is on a line BETWEEN two actual roots. In that case, the sequence
explodes into chaos, with results that diverge more and more wildly as
you continue the iteration.
This fractal type shows the results for the polynomial Z^n - 1, which
has n roots in the complex plane. Use the <T>ype command and enter
"newtbasin" in response to the prompt. You will be asked for a parame-
ter, the "order" of the equation (an integer from 3 through 10 -- 3 for
x^3 - 1, 7 for x^7-1, etc.).
The striped coloring of the plot shows the "basins of attraction" for
each root of the polynomial -- i.e., an initial guess within any area
of a given color would lead you to one of the roots. As you can see,
things get a bit weird along certain radial lines or "spokes," those
being the lines between actual roots. By "weird," we mean infinitely
complex in the good old fractal sense. Zoom in and see for yourself.
This fractal type is symmetric about the origin, with the number of
"spokes" depending on the order you select. It uses floating-point
math if you have an FPU, or a somewhat slower integer algorithm if
you don't have one.
NEWTON (type=newton)
The generating formula here is identical to that for newtbasin, but the
coloring scheme is different. Pixels are colored not according to the
root that would be "converged on" if you started using Newton's formula
from that point, but according to the iteration when the value is close
to a root. For example, if the calculations for a particular pixel
converge to the 7th root on the 23rd iteration, NEWTBASIN will color
that pixel using color #7, but NEWTON will color it using color #23.
If you have a 256-color mode, use it: the effects can be much livelier
than those you get with type=newtbasin, and color cycling becomes,
like, downright cosmic. If your "corners" choice is symmetrical,
FRACTINT exploits the symmetry for faster display. There is symmetry in
newtbasin, too, but the current version of the software isn't smart
enough to exploit it.
The applicable "params=" values are the same as newtbasin. Try
"params=4." Other values are 3 through 10. 8 has twice the symmetry and
is faster. As with newtbasin, an FPU helps.
COMPLEX NEWTON (type=complexnewton and type=complexbasin)
Well, hey, "Z^n - 1" is so boring when you can use "Z^a - b" where
"a" and "b" are complex numbers! The new "complexnewton" and
"complexbasin" fractal types are just the old "newton" and "newtbasin"
fractal types with this little added twist. When you select these
fractal types, you are prompted for four values (the real and imaginary
portions of "a" and "b"). If "a" has a complex portion, the fractal
has a discontinuity along the negative axis - relax, we finally figured
out that it's *supposed* to be there!
LAMBDA SETS (type=lambda)
This type calculates the Julia set of the formula lambda*Z*(1-Z). That
is, the value Z[0] is initialized with the value corresponding to each
pixel position, and the formula iterated. The pixel is colored accord-
ing to the iteration when the sum of the squares of the real and
imaginary parts exceeds 4. See this space in future versions for a
profound discussion of the physical significance of this formula, if we
ever figure it out!
Two parameters, the real and imaginary parts of lambda, are required.
Try 0 and 1 to see the classical fractal "dragon". Then try 0.2 and 1
for a lot more detail to zoom in on.
PLASMA CLOUDS (type=plasma)
Plasma clouds ARE real live fractals , even though we didn't know it at
first. They are generated by a recursive algorithm that randomly picks
colors of the corner of a rectangle, and then continues recursively
quartering previous rectangles. Random colors are averaged with those
of the outer rectangles so that small neighborhoods do not show much
change, for a smoothed-out, cloud-like effect. The more colors your
video mode supports, the better. The result, believe it or not, is
a fractal landscape viewed as a contour map, with colors indicating
constant elevation. To see this, save and view with the "3" command
(see section on 3D), and your "cloud" will be converted to a mountain!
You've GOT to try palette cycling on these (hit "+" or "-"). If you
haven't been hypnotized by the drawing process, the writhing colors
will do it for sure. We have now implemented subliminal messages to
exploit the user's vulnerable state; their content varies with your
bank balance, politics, gender, accessibility to a FRACTINT
programmer, and so on. A free copy of Microsoft C to the first person
who spots them.
This type accepts a single parameter, which determines how abruptly the
colors change. A value of .5 yields bland clouds, while 50 yields very
grainy ones. The default value is 2. Zooming is ignored, as each
plasma-cloud screen is generated randomly.
The algorithm is based on the Pascal program distributed by Bret Mulvey
as PLASMA.ARC. We have ported it to C and integrated it with FRACTINT's
graphics and animation facilities. This implementation does not use
floating-point math.
Saved plasma-cloud screens are EXCELLENT starting images for fractal
"landscapes" created with the "3D" options.
LAMBDA*SINE/COSINE/SINH/COSH/EXPONENT (type=lambdasine,
lambdacos, lambdasinh, lambdacos, lambdaexp)
These types calculate the Julia set of the formulas lambda*sine(Z),
lambda*cosine(Z), lambda*sinh(Z), lambda*cosh(Z), or
lambda*exp(Z), where lambda and Z are both complex. Two values,
the real and imaginary parts of lambda, should be given in the
"params=" option. For the feathery, nested spirals of
LambdaSines and the frost-on-glass patterns of LambdaCosines,
make the real part = 1, and try values for the imaginary part
ranging from 0.1 to 0.4 (hint: values near 0.4 have the best
patterns). In these ranges the Julia set "explodes". For the
tongues and blobs of LambdaExponents, try a real part of 0.379
and an imaginary part of 0.479.
A co-processor used to be almost mandatory: each
LambdaSine/Cosine iteration calculates a hyperbolic sine,
hyperbolic cosine, a sine, and a cosine (the LambdaExponent
iteration "only" requires an exponent, sine, and cosine
operation)! However, FRACTINT now computes these transcendental
functions with fast integer math. In a few cases the fast math is
less accurate, so we have kept the old slow floating point code.
To use the old code, invoke with the float=yes option, and, if
you DON'T have a co-processor, go on a LONG vacation!
MANDEL*SINE/COSINE/SINH/COSH/EXPONENT (type=mandelsine,
mandelcos, mandelsinh, mandelcosh, mandelexp)
These are "pseudo-Mandelbrot" mappings for the
LambdaSine/Cos/Sinh/Cosh/Exp Julia functions. They map to their
corresponding Julia sets via the spacebar command in exactly the
same fashion as the original M/J sets. In general, they are
interesting mainly because of that property (the MandelExp set in
particular is rather boring). Generate the appropriate
"Mandeltrig" set, zoom on a likely spot where the colors are
changing rapidly, and hit the space-bar key to plot the Julia set
for that particular point.
Try "FRACTINT TYPE=MANDELCOS CORNERS=4.68/4.76/-.03/.03" for a
graphic demonstration that we're not taking Mandelbrot's name in vain
here. We didn't even know these little buggers were here until Mark
Peterson found this a few hours before the version incorporating
Mandeltrigs was released.
BARNSLEY MANDELBROT/JULIA SETS (type=barnsleym1/m2/j1/j2/m3/j3)
Michael Barnsley has written a fascinating college-level text,
"Fractals Everywhere," on fractal geometry and its graphic applica-
tions. (See the bibliography, App. D.) In it, he applies the principle
of the M and J sets to more general functions of two complex variables.
We have incorporated three of Barnsley's examples in FRACTINT. Their
appearance suggests polarized-light microphotographs of minerals, with
patterns that are less organic and more crystalline than those of the
M/J sets. Each example has both a "Mandelbrot" and a "Julia" type.
Toggle between them using the space bar.
The parameters have the same meaning as they do for the "regular"
Mandelbrot and Julia. For types M1, M2, and M3, they are used to "warp"
the image by setting the initial value of Z. For the types J1 through
J3, they are the values of C in the generating formulas, found in App. A.
Be sure to try the <O>rbit function while plotting these types.
BARNSLEY IFS FRACTALS (type=ifs, ifs3d)
One of the most remarkable spin-offs of fractal geometry is the ability
to "encode" realistic images in very small sets of numbers -- parame-
ters for a set of functions that map a region of two-dimensional space
onto itself. In principle (and increasingly in practice), a scene of
any level of complexity and detail can be stored as a handful of
numbers, achieving amazing "compression" ratios... how about a super-
VGA image of a forest, more than 300,000 pixels at eight bits apiece,
from a 1-KB "seed" file?
Again, Michael Barnsley and his co-workers at the Georgia Institute of
Technology are to be thanked for pushing the development of these
iterated function systems (IFS).
Invoking FRACTINT with "TYPE=ifs" defaults to an IFS "fern". Other IFS
images can be created via the FERN, TRIANGLE and TREE files included
with FRACTINT, or from user-written files with the default extension
.IFS. Use the command-line argument "IFS=filename" or the main-menu <I>
command to use or manipulate one of these files. Specify whether 2D or
"3D" if you have not already chosen an IFS type. You will then be asked
to pick which function to edit. Hitting <Enter> leaves values
unchanged.
Each line in an IFS code file contains the parameters for one of the
generating functions, e.g. in FERN.IFS:
a b c d e f p
___________________________________
0 0 0 .16 0 0 .01
.85 .04 -.04 .85 0 1.6 .85
.2 -.26 .23 .22 0 1.6 .07
-.15 .28 .26 .24 0 .44 .07
The "p" values are the probabilities assigned to each function (how
often it is used), which add up to one. FRACTINT supports up to 32
functions, although usually three or four are enough.
Note that some Barnsley IFS values generate images quite a bit smaller
than the initial (default) screen. Just bring up the zoom box, center
it on the small image, and hit the ENTER key to get a full-screen
image.
In order to fully appreciate the 3D fern, since your monitor is presum-
ably 2D, we have added rotation, translation, and perspective capabili-
ties. These share values with the same variables used in FRACTINT's
other 3D facilities; for their meaning see "3D Images", farther on in
this section. You can enter these values from the command line using:
rotation=xrot/yrot/zrot (try 30/30/30)
shift=xshift/yshift (shifts BEFORE applying perspective!)
perspective=viewerposition (try 200)
Alternatively, entering "e" (for edit) from main screen or entering
a "t" (for "transformations") from the IFS 3D codes-editing screen, will
allow you to edit these values. The defaults are the same as for regular
3D, and are not always optimum for the 3D fern. Try rotation=30/30/30.
Note that applying shift when using perspective changes the picture --
your "point of view" is moved.
A truly wild variation of 3D may be seen by entering "2" for the stereo
mode, putting on red/blue "funny glasses", and watching the fern develop
with full depth perception right there before your eyes!
This feature is STILL dedicated to Bruce Goren, as a bribe to get him to
send us MORE knockout stereo slides of 3D ferns, now that we have made it
so easy!
SIERPINSKI GASKET (type=sierpinski)
Another pre-Mandelbrot classic, this one found by W. Sierpinski around
World War I. It is generated by dividing a triangle into four congruent
smaller triangles, doing the same to each of them, and so on, yea, even
unto infinity. (Notice how hard we try to avoid reiterating "iterat-
ing"?)
If you think of the interior triangles as "holes", they occupy more and
more of the total area, while the "solid" portion becomes as hopelessly
fragile as that gasket you HAD to remove without damaging it -- you
remember, that Sunday afternoon when all the parts stores were closed?
There's a three-dimensional equivalent using nested tetrahedrons
instead of triangles, but it generates too much pyramid power to be
safely unleashed yet.
There are no parameters for this type. We were able to implement it
with integer math routines, so it runs fairly quickly even without an
FPU.
QUARTIC MANDELBROT AND JULIA (type=mandel4, julia4)
These fractal types are the moral equivalent of the original M and J
sets, except that they use the formula Z(n+1) = Z(n)^4 + C, which adds
additional pseudo-symmetries to the plots. The "Mandel4" set maps to
the "Julia4" set via -- surprise! -- the spacebar toggle. The M4 set is
kind of boring at first (the area between the "inside" and the "out-
side" of the set is pretty thin, and it tends to take a few zooms to
get to any interesting sections), but it looks nice once you get there.
The Julia sets look nice right from the start.
Other powers, like Z(n)^3 or Z(n)^7, work in exactly the same fashion.
We used this one only because we're lazy, and Z(n)^4 = (Z(n)^2)^2.
DISTANCE ESTIMATOR MANDELBROT AND JULIA (type=demm, demj)
These are Phil Wilson's implementation of an alternate method for the M
and J sets, based on work by mathematician John Milnor and described in
"The Science of Fractal Images", p. 198. They produce more evenly
spaced contours; while they take full advantage of your color palette,
one of their best uses is in preparing monochrome images for a printer.
Using the 1600x1200x2 disk-video mode and an HP LaserJet, we have
produced pictures of quality equivalent to the black and white illus-
trations of the M-set in "The Beauty of Fractals."
Unfortunately, these images can take many hours to calculate even on a
fast machine with a coprocessor. One way of dealing with this is to use
the fast type=mandel and type=julia modes to find interesting areas.
Frame these nicely, then hit B to save the coordinates to FRABATCH.BAT.
Edit the batch file, changing TYPE to "demm" or "demj", MODE to a high-
resolution monochrome disk-video mode, and MAXITER to 1000 or so. Run
the batch file when you won't be needing your machine (over the week-
end?) and print the resulting .FRA file at your convenience.
PICKOVER MANDELBROT/JULIA TYPES (type=mansinzsqrd/julsinzsqrd,
manzpowr/julzpowr,manzzpwr/julzzpwr, mansinexp/julsinexp)
These types have been explored by Clifford A. Pickover, of the IBM Thomas
J. Watson Research center. As implemented in FRACTINT, they are regular
Mandelbrot/Julia set pairs that may be plotted with or without the
"biomorph" option Pickover used to create organic-looking beasties (see
below). These types are produced with formulas built from the functions
z^z, z^n, sin(z), and e^z for complex z. Types with "power" or "pwr"
in their name have an exponent value as a third parameter. For
example, type=manzpower params=0/0/2 is our old friend the
classical Mandelbrot, and type=manzpower params=0/0/4 is the
Quartic Mandelbrot. Other values of the exponent give still other
fractals. Since these WERE the original "biomorph" types, we
should give an example. Try:
FRACTINT type=mansinsqrd biomorph=0 corners=-8/8/-6/6
to see a big biomorph digesting little biomorphs!
PICKOVER POPCORN (type=popcorn)
Here is another Pickover idea. This one computes and plots the
orbits of the dynamic system defined by:
x(n+1) = x(n) - h*sin(y(n)+tan(3*y(n))
y(n+1) = y(n) - h*sin(x(n)+tan(3*x(n))
with the initializers x(0) and y(0) equal to ALL the complex
values within the "corners" values, and h=.01. ALL these orbits
are superimposed, resulting in "popcorn" effect. As a bonus, for
reasons known only to the programmers, give the option
"symmetry=none" and you will see the Julia set generated by these
same equations with the usual escape-time coloring. Turn on orbit
viewing with the "O" command, and as you watch the orbit pattern
you may get some insite as to where the popcorn comes from. You
may want to use a maxiter value less than normal - Pickover
recommends a value of 50.
All these are generated by equations are of the form z(k+1) = f(z(k),c),
where the function orbit is the sequence z(0), z(1), ..., and the variable
c is a complex parameter of the equation. The value c is fixed for Julia
sets and is equal to the first two parameters entered with the "params=
Creal/Cimag" command. The initial orbit value z(0) is the complex number
corresponding to the screen pixel. For Mandelbrot sets, the parameter c is
the complex number corresponding to the screen pixel. The value z(0) is c
plus a perturbation equal to the values of the first two
params=perturbx/perturby values.
Some equations have an additional parameter n, which is generally
an exponent. This value is entered as the third params= value
for both Julia and Mandelbrot sets. The variables x and y refer
to the real and imaginary parts of z; similarly, cx and cy are the
real and imaginary parts of the parameter c and fx(z) and fy(z)
are the real and imaginary parts of f(z). The variable c is
sometimes called lambda for historical reasons.
PETERSON VARIATIONS (type=marksmandel, marksjulia, mandellambda,
cmplxmarksmand, cmplxmarksjul)
These fractal types are contributions of Mark Peterson. MarksMandel and
MarksJulia are two families of fractal types that are linked in the
same manner as the classic Mandelbrot/Julia sets: each MarksMandel set
can be considered as a mapping into the MarksJulia sets, and is linked
with the spacebar toggle. The basic equation for these sets is:
Z(n+1) = ((lambda^n) * Z(n)^2) + lambda
where Z(0) = 0.0 and lambda is (x + iy) for MarksMandel. For
MarksJulia, Z(0) = (x + iy) and lambda is a constant (taken from the
MarksMandel spacebar toggle, if that method is used). The exponent is a
positive integer or a complex number. We call these "families" because
each value of the exponent yields a different MarksMandel set, which turns
out to be a kinda-polygon with (exponent+1) sides. The exponent value is the
third parameter, after the "initialization warping" values. Typically one
would use null warping values, and specify the exponent with something
like "PARAMS=0/0/4", which creates an unwarped, pentagonal MarksMandel
set.
MandelLambda maps the lambda function in the same way that the M-set
maps J sets, and is linked to the lambda function with the spacebar
toggle.
UNITY (type=unity)
This Peterson variation began with curiosity about other "Newton-style"
approximation processes. A simple one,
One = (x * x) + (y * y);
y = (2 - One) * x;
x = (2 - One) * y;
produces the fractal called Unity.
One of its interesting features is the "ghost lines." The iteration
loop bails out when it reaches the number 1 to within the resolution of
a screen pixel. When you zoom a section of the image, the bailout
criterion is adjusted, causing some lines to become thinner and others
thicker.
Only one line in Unity that forms a perfect circle: the one at a radius
of 1 from the origin. This line is actually infinitely thin. Zooming on
it reveals only a thinner line, up (down?) to the limit of accuracy for
the algorithm. The same thing happens with other lines in the fractal,
such as those around |x| = |y| = (1/2)^(1/2) = .7071
Try some other tortuous approximations using the TEST stub (see below)
and let us know what you come up with!
BIFURCATION (type=bifurcation)
The wonder of fractal geometry is that such complex forms can arise
from such simple generating processes. A parallel surprise has emerged
in the study of dynamical systems: that simple, deterministic equations
can yield chaotic behavior, in which the system never settles down to a
steady state or even a periodic loop. Often such systems behave normal-
ly up to a certain level of some controlling parameter, then go through
a transition in which there are two possible solutions, then four, and
finally a chaotic array of possibilities.
This emerged many years ago in biological models of population growth.
Consider a (highly over-simplified) model in which the rate of growth
is partly a function of the size of the current population:
New Population = Growth Rate * Old Population * (1 - Old Population)
where population is normalized to be between 0 and 1. At growth rates
less than 200 percent, this model is stable: for any starting value,
after several generations the population settles down to a stable
level. But for rates over 200 percent, the equation's curve splits or
"bifurcates" into two discrete solutions, then four, and soon becomes
chaotic.
Type=bifurcation illustrates this model. (Although it's now considered
a poor one for real populations, it helped get people thinking about
chaotic systems.) The horizontal axis represents growth rates, from 190
percent (far left) to 400 percent; the vertical axis normalized popula-
tion values, from 0 to 4/3. Notice that within the chaotic region,
there are narrow bands where there is a small, odd number of stable
values. It turns out that the geometry of this branching is -- hot
damn! -- fractal; zoom in where changing pixel colors look suspicious,
and see for yourself.
The default display has been filtered by allowing the population to
settle from its initial value for 5000 cycles before plotting maxiter
population values. To override this filter value, specify a new (small-
er) one as the first "PARAMS=" value. "PARAMS=1" produces an unfiltered
map.
LORENZ ATTRACTORS (type=lorenz and type=lorenz3d)
The "Lorenz Attractor" is a "simple" set of three deterministic equations
developed by Edward Lorenz while studying the non-repeatability of
weather patterns. The weather forecaster's basic problem is that even
very tiny changes in initial patterns ("the beating of a butterfly's
wings" - the official term is "sensitive dependence on initial conditions")
eventually reduces the best weather forecast to rubble.
The lorenz attractor is the plot of the orbit of a dynamic system
consisting of three first order non-linear differential equations.
The solution to the differential equation is vector-valued function of
one variable. If you think of the variable as time, the solution traces an
orbit. The orbit is made up of two spirals at an angle to each other in
three dimensions. We change the orbit color as time goes on to add a little
dazzle to the image. The equations are:
dx/dt = -a*x + a*y
dy/dt = b*x - y -z*x
dz/dt = -c*z + x*y
We solve these differential equations approximately using a method known as
the first order taylor series. Calculus teachers everywhere will kill us
for saying this, but you treat the notation for the derivative dx/dt as though
it really is a fraction, with "dx" the small change in x that happens when the
time changes "dt". So multiply through the above equations by dt, and you
will have the change in the orbit for a small time step. We add these changes
to the old vector to get the new vector after one step. This gives us:
xnew = x + (-a*x*dt) + (a*y*dt)
ynew = y + (b*x*dt) - (y*dt) - (z*x*dt)
znew = z + (-c*z*dt) + (x*y*dt)
(default values: dt = .02, a = 5, b = 15, c = 1)
We connect the successive points with a line, project the resulting 3D orbit
onto the screen, and voila! The Lorenz Attractor!
We have added two versions of the Lorenz Attractor. "Type=lorenz"
is the Lorenz attractor as seen in everyday 2D. "Type=lorenz3d"
is the same set of equations with the added twist that the results
are run through our perspective 3D routines, so that you get to view
it from different angles (you can modify your perspective "on the fly"
using the transformation option of the <E>ditor command.) If you set
the "stereo" option to "2", and have red/blue funny glasses on, you will
see the attractor orbit with depth perception.
Hint: the default perspective values (x = 60, y = 30, z = 0) aren't the
best ones to use for fun Lorenz Attractor viewing. Experiment a bit -
start with rotation values of 0/0/0 and then change to 20/0/0 and 40/0/0
to see the attractor from different angles.- and while you're at it, use a
non-zero perspective point Try 100 and see what happens when you get
*inside* the Lorenz orbits. Here comes one - Duck! While you are at it,
turn on the sound with the "X". This way you'll at least hear it coming!
Different Lorenz attractors can be created using different
parameters. Four parameters are used. The first is the time-step (dt).
The default value is .02. A smaller value makes the plotting go
slower; a larger value is faster but rougher. A line is drawn to
connect successive orbit values. The 2nd, third, and fourth parameters
are cofficients used in the differential equation (a, b, and c). The
default values are 5, 15, and 1. Try changing these a little at a
time to see the result.
ROSSLER ATTRACTORS (type=rossler3D)
This fractal is named after the German Otto Rossler, a non-practicing medical
doctor who approached chaos with a bemusedly philosophical attitude. He would
see strange attractors as philosophical objects. His fractal namesake looks
like a band of ribbon with a fold in it. All we can say is we used the same
calculus-teacher-defeating trick of multiplying the equations by "dt" to
solve the differential equation and generate the orbit. This time we will
skip straight to the orbit generator -if you followed what we did above with
Lorenz you can easily reverse engineer the differential equations.
xnew = x - y*dt - z*dt
ynew = y + x*dt + a*y*dt
znew = z + b*dt + x*z*dt - c*z*dt
Default parameters are dt = .04, a = .2, b = .2, c = 5.7
HENON ATTRACTORS (type=henon)
Michel Henon was an astronomer at Nice observatory in southern France. He
came to the subject of fractals via investigations of the orbits of
astronomical objects. The strange attractor most often linked with Henon's
name comes not from a differential equation, but from the world of discrete
mathematics - difference equations. The Henon map is an example of a
very simple dynamic system that exhibits strange behavior. The orbit traces
out a characteristic banana shape, but on close inspection, the shape is made
up of thicker and thinner parts. Upon magnification, the thicker bands
resolve to still other thick and thin components. And so it goes forever!
The equations that generate this strange pattern perform the mathematical
equivalent of repeated stretching and folding, over and over again.
xnew = 1 + y - a*x*x
ynew = b*x
The default parameters are a=1.4 and b=.3.
PICKOVER ATTRACTORS (type=pickover)
Clifford A. Pickover of the IBM Thomas J. Watson Research center is such
a creative source for fractals that we attach his name to this one only
with great trepidation. Probably tomorrow he'll come up with another one
and we'll be back to square one trying to figure out a name!
This one is the three dimensional orbit defined by:
xnew = sin(a*y) - z*cos(b*x)
ynew = z*sin(c*x) - cos(d*y)
znew = sin(x)
Default parameters are: a = 2.24, b = .43, c = -.65, d = -2.43
GINGERBREADMAN FRACTAL (type=gingerbread)
This simple fractal is a charming example stolen from "Science of Fractal
Images", p. 149. Look closely, and you will see that the gingerbreadman
contains infinitely many copies of himself at all different scales.
xnew = 1 - y + |x|
ynew = x
There are no parameters.
TEST (type=test)
This is a stub that we (and you!) use for trying out new fractal types.
"Type=test" fractals make use of FRACTINT's structure and features for
whatever code is in the routine 'testpt()' (located in the small source
file TESTPT.C) to determine the color of a particular pixel.
If you have a favorite fractal type that you believe would fit nicely
into FRACTINT, just rewrite the C function in TESTPT.C (or use the
prototype function there, which is a simple M-set implementation) with
an algorithm that computes a color based on a point in the complex
plane.
After you get it working, send your code to one of the authors and we
might just add it to the next release of FRACTINT, with full credit to
you. Our criteria are: 1) an interesting image and 2) a formula signif-
icantly different from types already supported. (Bribery may also work.
THIS author is completely honest, but I don't trust those other guys.)
Be sure to include an explanation of your algorithm and the parameters
supported, preferably formatted as you see here to simplify folding it
into the documentation.
FORMULA (type=formula)
Fractint now has a new 'type=formula' fractal type. This is a
"roll-your-own" fractal interpreter - you don't even need a compiler!
To run a "type=formula" fractal, you first need to build a text file
containing formulas (there's a sample file - FRACTINT.FRM - included
with this distribution). When you select the "formula" fractal type,
you are prompted first for the name of your file. Then, after the
program locates the file and scans it for formulas, you are prompted
for the formula name you wish to run. After prompting for any
parameters, the formula is parsed for syntax errors and then the
fractal is generated.
There are also two new command-line options that work with type=formula
("formulafile=" and "formulaname=") if you are using this new fractal
type in batch mode.
(the following documentation is supplied by Mark Peterson, who wrote the
formula interpreter):
Formula fractals allow you to create your own fractal formulas. The
general format is:
Mandelbrot(XAXIS) { z = Pixel: z = sqr(z) + pixel, |z| <= 4 }
| | | | |
Name Symmetry Initial Iteration Bailout
Condition Criteria
Initial conditions are set, then the iterations performed until the
bailout criteria is true or 'z' turns into a periodic loop.
All variables are created automatically by their usage and treated as
complex. If you declare 'v = 2' then the variable 'v' is treated as a
complex with an imaginary value of zero.
Predefined Variables (x, y)
--------------------------------------------
z used for periodicity checking
p1 parameters 1 and 2
p2 parameters 3 and 4
pixel screen coordinates
Precedence
--------------------------------------------
1 sin(), cos(), sinh(), cosh(), sqr(),
log(), exp(), abs(), conj(), real(),
imag()
2 - (negation), ^ (power)
3 * (multiplication), / (division)
4 + (addition), - (subtraction)
5 = (assignment)
6 < (less than), <= (less than or equal to)
Precedence may be overridden by use of parenthesis. Note the modulas
squared operator |z| is also parenthetic and always sets the imaginary
component to zero. This means 'c * |z - 4|' first subtracts 4 from z,
calculates the modulas squared then multiplies times 'c'. Nested
modulas squared operators require overriding parenthesis:
c * |z + (|pixel|)|
The formulas are performed using either integer or floating point
mathematics depending on the type of math you have setup. If you do
not have an FPU then type MPC math is performed in leu of traditional
floating point.
Remember that when using integer math there is a limited dynamic
range, so what you think may be a fractal could really be just a
limitation of the integer math range. God may work with integers, but
His dynamic range is many orders of magnitude greater than our puny 32
bit mathematics! Always verify with the floating point.
JULIBROTS (type=julibrot)
(the following documentation is supplied by Mark Peterson, who "invented"
the Julibrot algorithm)
There is a very close relationship between the Mandelbrot set and
Julia sets of the same equation. To draw a Julia set you take the
basic equation and vary the initial value according to the two
dimensions of screen leaving the constant untouched. This method
diagrams two dimensions of the equation, 'x' and 'iy', which I refer
to as the Julia x and y.
z(0) = screen coordinate (x + iy)
z(1) = (z(0) * z(0)) + c, where c = (a + ib)
z(2) = (z(1) * z(0)) + c
z(3) = . . . .
The Mandelbrot set is a composite of all the Julia sets. If you take
the center pixel of each Julia set and plot it on the screen
coordinate corresponding to the value of c, a + ib, then you have the
Mandelbrot set.
z(0) = 0
z(1) = (z(0) * z(0)) + c, where c = screen coordinate (a + ib)
z(2) = (z(1) * z(1)) + c
z(3) = . . . .
I refer to the 'a' and 'ib' components of 'c' as the Mandelbrot 'x'
and 'y'.
All the 2 dimensional Julia sets correspond to a single point on the 2
dimensional Mandelbrot set, making a total of 4 dimensions associated
with our equation. Visualizing 4 dimensional objects is not as
difficult as it may sound at first if you consider we live in a 4
dimensional world. The room around you is three dimensions and as you
read this text you are moving through the fourth dimension of time.
You and everything around your are 4 dimensional objects - which is to
say 3 dimensional objects moving through time. We can think of the 4
dimensions of our equation in the same manner, this is as a 3
dimensional object evolving over time - sort of a 3 dimensional
fractal movie. The fun part of it is you get to pick the dimension
representing time!
To construct the 4 dimensional object into something you can view on
the computer screen you start with the simple 2 dimensions of the
Julia set. I'll treat the two Julia dimensions as the spacial
dimensions of height and width, and the Mandelbrot 'y' dimension as
the third spacial dimension of depth. This leaves the Mandelbrot 'x'
dimension as time. Draw the Julia set associated with the Mandelbrot
coordinate (-.83, -.25), but instead of setting the color according to
the iteration level it bailed out on, make it a two color drawing
where the pixels are black for iteration levels less than 30, and
another color for iteration levels greater than or equal to 30. Now
increment the Mandelbrot 'y' coordinate by a little bit, say (-.83, -
.2485), and draw another Julia set in the same manner using a
different color for bailout values of 30 or greater. Continue doing
this until you reach (-.83, .25). You now have a three dimensional
representation of the equation at time -.83. If you make the same
drawings for points in time before and after -.83 you can construct a
3 dimensional movie of the equation which essentially is a full 4
dimensional representation.
In the Julibrot fractal available with this release of FRACTINT the
spacial dimensions of height and width are always the Julia
dimensions. The dimension of depth is determined by the Mandelbrot
coordinates. The program will consider the dimension of depth as the
line between the two Mandelbrot points. To draw the image in our
previous example you would set the 'From Mandelbrot' to (-.83, .25)
and the 'To Mandelbrot' as (-.83, -.25). If you set the number of 'z'
pixels to 128 then the program will draw the 128 Julia sets found
between Mandelbrot points (-.83, .25) and (-.83, -.25). To speed
things up the program doesn't actually calculate ALL the coordinates
of the Julia sets. It starts with the a pixel a the Julia set closest
to the observer and moves into the screen until it either reaches the
required bailout or the limit to the range of depth.
Zooming can be done in the same manner as with other fractals. The
visual effect (with other values unchanged) is similar to putting the
boxed section under a pair of magnifying glasses.
The variable associated with penetration level is the level of bailout
there you decide to make the fractal solid. In other words all
bailout levels less than the penetration level are considered to be
transparent, and those equal or greater to be opaque. The farther
away the apparent pixel is the dimmer the color.
The remainder of the parameters are needed to construct the red/blue
picture so that the fractal appears with the desired depth and proper
'z' location. With the origin set to 8 inches beyond the screen plane
and the depth of the fractal at 8 inches the default fractal will
appear to start at 4 inches beyond the screen and extend to 12 inches
if your eyeballs are 2.5 inches apart and located at a distance of 24
inches from the screen. The screen dimensions provide the reference
frame.
To the human eye blue appears brighter than red. The Blue:Red ratio
is used to compensate for this fact. If the image appears reddish
through the glasses raise this value until the image appears to be in
shades of grey. If it appears bluish lower the ratio.
Julibrots can only be shown in 256 red/blue colors for viewing in either
stero-graphic (red/blue funny glasses) or grey-scaled. FRACTINT
automatically loads either GLASSES1.MAP or ALTERN.MAP as appropriate.
DIFFUSION LIMITED AGGREGATION (type=diffusion)
This type begins with a single point in the center of the screen. Subsequent
points move around randomly until coming into contact with the first point, at
which time their locations are fixed and they are colored randomly. This
process repeats until the fractals reaches the edge of the screen. Use the
show orbits function to see the points' random motion.
One unfortunate problem is that on a large screen, this process will tend to
take eons. To speed things up, the points are restricted to a box around the
initial point. The first and only parameter to diffusion contains the size of
the border between the fractal and the edge of the box. If you make this
number small, the fractal will look more solid and will be generated more
quickly.
Diffusion was inspired by a Scientific American article a couple of years back
which includes actual pictures of real physical phenomena that behave like
this.
Thanks to Adrian Mariano for providing the diffusion code and documentation.
"3D" IMAGES
FRACTINT can now restore images in "3D". Important: we use quotation
marks because it does not CREATE images of 3D fractal objects (there
are such, but we're not there yet.) Instead, it restores .FRA images
(or .GIF images -- see Sec. 4) as a 3D PROJECTION or STEREO IMAGE
PAIR. The iteration values you've come to know and love, the ones that
determine pixel colors, are translated into "height" so that your
saved screen becomes a landscape viewed in perspective. You can even
wrap the landscape onto a sphere for realistic-looking planets and
moons that never existed outside your PC!
We suggest starting with a saved plasma-cloud screen. Hit <3> in main
command mode to begin the process, enter the filename. If no extension
is specified, a .FRA extension is assumed. If no .FRA is found, it
will assume a .GIF extension. If no match is then found, if will
attempt to match the file with no extension. Then it will prompt you
for the video mode if appropriate.
Now, you'll be bombarded with a long series of options. Not to worry:
all of them have defaults chosen to yield an acceptable starting
image, so the first time out just pump your way through with the
<Enter> key. When you enter a different value for any option, that
becomes the default value the next time you hit <3>, so you can change
one option at a time until you get what you want. Generally <ESC> will
take you back to the previous screen.
3D MODE SELECTION
After the filename prompt and video mode check, you're presented with
a "3d Mode Selection" screen. Each selection will have defaults
entered if you wish to change any of the defaults use the cursor keys
to move through the menu. When you're satisfied press <Enter>.
Here are the options and what they do:
Preview Mode:
Preview mode provides a rapid look at your transformed image
using by skipping a lot of rows and filling the image in. Good
for quickly discovering the best parameters. Let's face it, the
FRACTINT authors most famous for "blazingly fast" code *DIDN'T*
write the 3D routines!
Show Box:
If you have selected Preview Mode you have another option to
worry about. This is the option to show the image box in scaled
and rotated coordinates x, y, and z. The box only appears in
rectangular transformations and shows how the final image will be
oriented. If you select light source in the next screen, it will
also show you the light source vector so you can tell where the
light is coming from in relation to your image. Sorry no head or
tail on the vector yet.
Coarseness:
This sets how many divisions the image will be divided into
in the y direction, if you select preview mode above, or
grid fill in the "Select Fill Type" screen next.
Spherical Projection:
The next question asks if you want a sphere projection. This will
take your image and map it onto a plane if you answer "no" or a
sphere if you answer "yes" as described above. Try it and you'll
see what we mean.
Stereo:
Sound in FRACTINT? Well, not yet. FRACTINT now allows you to
create 3D images for use with red/blue glasses like 3D
comics you may have seen, or images like Captain EO.
Option 0 is normal old 3D you can look at with just your
eyes.
Options 1 and 2 require the special red/blue-green glasses.
They are meant to be viewed right on the screen or on a
color print off of the screen. The image can be made to
hover entirely or partially in front of the screen. Great
fun! These two options give a gray scale image when viewed.
Option 1 gives 64 shades of gray but with half the spatial
resolution you have selected. It works by writing the red and
blue images on adjacent pixels, which is why it eats half your
resolution. In general, we recommend you use this only with
resolutions above 640x350. Use this mode for continuous potential
landscapes where you *NEED* all those shades.
Option "2" gives you full spatial resolution but with only 16
shades of gray. If the red and blue images overlap, the colors
are mixed. Good for wire-frame images, lorenz3d and ifs3d. Works
fine in 16 color modes.
Option 3 is for creating stereo pair images for view later
with more specialized equipment. It allows full color images
to be presented in glorious stereo. The left image presented
on the screen first. You may photograph it or save it. Then
the second image is presented, you may do the same as the
first image. You can then take the two images and convert
them to a stereo image pair as outlined by Bruce Goren (see
below). When you are satisfied with your selections press
enter to go to the next screen which will appear below this
one.
SELECT FILL TYPE Screen
These options exist because in the course of the 3D projection,
portions of the original image may be stretched to fit the new
surface. Points of an image that formerly were right next to each
other, now may have a space between them. These options generally
determine what to do with the space between the mapped dots.
For an illustration, pick the second option "just draw the points",
which just maps points to corresponding points. Generally this will
leave empty space between many of the points. Therefore you can choose
various algorithms that "fill in" the space between the points in
various ways.
Now, try the first option "make a surface grid." This option will make
a grid of the surface which is as many divisions in the original "y"
direction as was set in "coarse" in the first screen. It is very fast,
and can give you a good idea what the final relationship of parts of
your picture will look like.
Try the second option, "connect the dots (wire frame)", then "surface
fills - (colors interpolated)" and "(colors not interpolated), the
general favorite of the authors. Solid fill, while it reveals the
pseudo-geology under your pseudo-landscape, inevitably takes longer.
Now try the light source fill types. These two algorithms allow
you to position the "sun" over your "landscape." Each pixel is
colored according to the angle the surface makes with an
imaginary light source. You will be asked to enter the three
coordinates of the vector pointing toward the light in one of the
following screens.
Light source before transformation calculates the illumination
before doing the coordinate transformations, and is slightly
faster. If you generate a sequence of images where one rotation
is progressively changed, the effect is as if the image and the
light source are fixed in relation to each other and you orbit
around the image.
Light source after transformation applies the transformations
first, then calculates the illumination. If you generate a
sequence of images with progressive rotation as above the effect
is as if you and the light source are fixed and the object is
rotating.
For ease of discussion we will refer to the following fill types
by their numbers:
-1 - surface grid
0 - (default) - no fill at all - just draw the dots.
1 - wire frame - joins points with lines
2 - surface fill - (colors interpolated)
3 - surface fill - (interpolation turned off)
4 - solid fill - draws lines from the "ground" up to the point
5 - surface fill with light model - calculated before 3D transforms
6 - surface fill with light model - calculated after 3D transforms
Types 2, 5, and 6 interpolate colors when filling, making a very
smooth fill if the palette is continuous. This may not be desirable if
the palette is not continuous. Type 3 is the same as type 2 with
interpolation turned off. You might want to use fill type 3, for
example, to project a .GIF photograph onto a sphere. With type 2, you
might see the filled-in points, since chances are the palette is not
continuous; type 3 fills those same points in with the colors of
adjacent pixels. However, for most fractal images, fill type 2 works
better.
STEREO 3D VIEWING
If you selected Stereo option 1, 2 or 3 you will be presented another
screen to select from. We suggest you definitely use defaults at first
on this one.
Funny Glasses Parameters
When you look at an image with both eyes, each eye sees the image in
slightly different perspective because they see it from different
places.
The first selection you must make is ocular separation, the distance
the between the viewers eyes. This is measured as a % of screen and is
an important factor in setting the position of the final stereo image
in front of or behind the CRT Screen.
The second selection is convergence, also as a % of screen. This
tends to move the image forward and back to set where it floats.
More positive values move the image towards the viewer. The value
of this parameter needs to be set in conjunction with the setting of
ocular separation and the perspective distance. It directly adjusts
the overall separation of the two stereo images. Beginning anaglyphers
love to create images floating mystically in front of the screen, but
grizzled old 3D veterans look upon such antics with disdain, and
believe the image should be safely inside the monitor where it
belongs!
Left and Right Red and Blue image crop (% of screen also) help
keep the visible part of the right image the same as the visible
part of the left by cropping them. If there is too much in the
field of either eye that the other doesn't see, the stereo effect
can be ruined.
Red and Blue brightness factor. The generally available red/blue-
green glasses, made for viewing on ink on paper and not the light
from a CRT, let in more red light in the blue-green lens than we
would like. This leaves a ghost of the red image on the blue-
green image (definitely not desired in stereo images). We have
countered this by adjusting the intensity of the red and blue
values on the CRT. In general you should not have to adjust this.
The final entry is Map file name. If you have a special map file
you want to use for Stereo 3D this is the place to enter its
name. Generally glasses1.map is for type 1 (alternating pixels), and
glasses2.map is for type 2 (superimposed pixels). Grid.map is great
for wire-frame images using 16 color modes.
RECTANGULAR COORDINATE TRANSFORMATION
The first entries are rotation values around the X, Y, and Z axes.
Think of your starting image as a flat map: the X value tilts the
bottom of your monitor towards you by X degrees, the Y value pulls the
left side of the monitor towards you, and the Z value spins it
counter-clockwise. Note that these are NOT independent rotations: the
image is rotated first along the X-axis, then along the Y-axis, and
finally along the Z-axis. Those are YOUR axes, not those of your (by
now hopelessly skewed) monitor. All rotations actually occur through
the center of the original image.
Then there are three scaling factors in per cent. Initially, leave the
X and Y axes alone and play with Z, now the vertical axis, which
translates into surface "roughness." High values of Z make spiky, on-
beyond-Alpine mountains and improbably deep valleys; low values make
gentle, rolling terrain. Negative roughness is legal: if you're doing
an M-set image and want Mandelbrot Lake to be below the ground,
instead of eerily floating above, try a roughness of about -30%.
Next we need a water level -- really a minimum-color value that
performs the function "if (color < waterlevel) color = waterlevel". So
it plots all colors "below" the one you choose at the level of that
color, with the effect of filling in "valleys" and converting them to
"lakes."
Now we enter a perspective distance, which you can think of as the
"distance" from your eye to the image. A zero value (the default)
means no perspective calculations, which allows use of a faster
algorithm.
For non-zero values, picture a box with the original X-Y plane of your
flat fractal on the bottom, and your 3D fractal inside. A perspective
value of 100% places your eye right at the edge of the box and yields
fairly severe distortion, like a close view through a wide-angle lens.
200% puts your eye as far from the front of the box as the back is
behind. 300% puts your eye twice as far from the front of the box as
the back is, etc. Try about 150% for reasonable results. Much larger
values put you far away for even less distortion, while values smaller
than 100% put you "inside" the box. Try larger values first, and work
your way in.
Finally, you are prompted for two types of X and Y shifts (now back in
the plane of your screen) that let you move the final image around if
you'd like to re-center it. The first set, x and y shift with
perspective, move the image and the effect changes the perspective you
see. The second set, "x and y adjust without perspective", move the
image but do not change perspective. They are used just for
positioning the final image on the screen
Well, OK, we lied. If you selected one of the light source fill
options, there are still MORE options.
You must chose the direction of the light from the light source. This
will be scaled in the x, y, and z directions the same as the image.
For example, 1,1,3 positions the light to come from the lower right
front of the screen in relation to the untransformed image. It is
important to remember that these coordinates are scaled the same as
your image. Thus 1,1,1 positions the light to come from a direction of
equal distances to the right, below and in front of each pixel on the
original image. However, if the x,y,z scale is set to 90,90,30 the
result will be from equal distances to the right and below each pixel
but from only 1/3 the distance in front of the screen ie. it will be
low in the sky, say, afternoon or morning.
Then you are asked for a smoothing factor. Unless you used continuous
potential (see Sec. 4) when generating the starting image, the illumi-
nation when using light source fills may appear "sparkly", like a
sandy beach in bright sun. A smoothing factor of 2 or 3 will allow you
to see the large-scale shapes better. But if your fractal is not a
plasma cloud and has features with sharply defined boundaries (e.g.
Mandelbrot Lake), the smoothing may cause the colors to run. This is a
feature, not a bug. (A copyrighted response of [your favorite
commercial soft-ware company here], used by permission.)
Author's note - smoothing is a historical relic dating back to
*BEFORE* we added continuous potential. If anyone actually *USES*
this, let us know - otherwise we'll probably take it out.
You'll probably want to adjust the final colors for fill types using
light source via color cycling. Try one of the more continuous
palettes (<F8> through <F10>), or load the GRAY palette with the
<A>lternate-map command.
Now, absolutely the last option (this time we mean it): you are asked
for a range of "transparent" colors, if any. This option is most
useful when using the <O>verlay command below. Enter the color range
(minimum and maximum value) for which you do not want to over-write
whatever may already be on the screen. The default is no transparency
(display everything).
Note that any image loaded up in 3D is treated as if it were a plasma
cloud: we have NO idea how to retain the ability to zoom and pan
around a 3D image that has been twisted, stretched, perspective-ized,
and water-leveled. Actually, we do, but it involves the kind of
hardware that Industrial Light & Magic, Pixar et al. use for feature
films. So if you'd like to send us a check equivalent to George Lucas'
net from the "Star Wars" series...
Now, lie down for a while in a quiet room with a damp washcloth on
your forehead. Feeling better? Good -- because it's time to go back
almost to the top of the 3D options and just say yes to:
SPHERICAL PROJECTION
Picture a globe lying on its side, "north" pole to the right. (It's
our planet, and we'll position it the way we like.) You will be
mapping the X and Y axes of the starting image to latitude and
longitude on the globe, so that what was a horizontal row of pixels
follows a line of longitude. The defaults exactly cover the hemisphere
facing you, from longitude 180 degrees (top) to 0 degrees (bottom) and
latitude -90 (left) to latitude 90 (right). By changing them you can
map the image to a piece of the hemisphere or wrap it clear around the
globe.
The next entry is for a radius factor that controls the over-all size
of the globe. All the rest of the entries are the same as in the
landscape projection. You may want less surface roughness for a
plausi-ble look, unless you prefer small worlds with big topography, a
la "The Little Prince."
WARNING: When the "construction" process begins at the edge of the
globe (default) or behind it, it's plotting points that will be hidden
by subsequent points as the process sweeps around the sphere toward
you. Our nifty hidden-point algorithms "know" this, and the first few
dozen lines may be invisible unless a high mountain happens to poke
over the horizon. If you start a spherical projection and the screen
stays black, wait for a while (a longer while for higher resolution or
fill type 6) to see if points start to appear. Would we lie to you? If
you're still waiting hours later, first check that the power's still
on, then consider a faster system.
Once you're familiar with the effects of the 3D option values you have
a variety of options on how to specify them. You can specify them all
on the command line (there ARE a lot of them so they may not all fit
within the DOS command line limits), with an SSTOOLS.INI file, or with
a command file.
Here's an example for you power FRACTINTers, the command
FRACTINT MYFILE SAVENAME=MY3D 3D= BATCH=YES
would make FRACTINT load MYFILE.FRA, re-plot it as a 3D landscape
(taking all of the defaults), save the result as MY3D.FRA, and exit to
DOS. By the time you've come back with that cup of coffee, you'll have
a new world to view, if not conquer.
3D OVERLAY MODE
While the <3> command creates its image on a blank screen, the <O>
command draws a second image over an existing displayed image. This
image can be any restored image from a <R> command or the result of a
just executed <3> command. So you can do a landscape, then hit <O> and
choose spherical projection to re-plot that image or another as a moon
in the sky above the landscape. <O> can be repeated as many times as
you like.
It's worth noting that not all that many years ago, one of us watched
Benoit Mandelbrot and fractal-graphics wizard Dick Voss creating just
such a moon-over-landscape image at IBM's research center in Yorktown
Heights, NY. The system was a large and impressive mainframe with
floating-point facilities bigger than the average minicomputer,
running LBLGRAPH -- what Mandelbrot calls "an independent-minded and
often very ill-mannered heap of graphics programs that originated in
work by Alex Hurwitz and Jack Wright of IBM Los Angeles."
We'd like to salute LBLGRAPH, its successors, and their creators,
because it was their graphic output (like "Planetrise over Labelgraph
Hill," plate C9 in Mandelbrot's "Fractal Geometry of Nature") that
helped turn fractal geometry from a mathematical curiosity into a
phenomenon. We'd also like to point out that it wasn't as fast, flexi-
ble or pretty as FRACTINT on a 386/16 PC with S-VGA graphics. Now, a
lot of the difference has to do with the incredible progress of micro-
processor power since then, so a lot of the credit should go to Intel
rather than to our highly tuned code. OK, twist our arms -- it IS
awfully good code.
SPECIAL NOTE FOR CGA OR HERCULES USERS
If you are one of those unfortunates with a CGA or Hercules 2-color
monochrome graphics, it is now possible for you to make 3D projection
images.
Try the following unfortunately circuitous approach. Invoke FRACTINT,
making sure you have set askvideo=yes. Use a diskvideo mode to create
a 256 color fractal. You might want to edit the fractint.cfg file to
make a diskvideo mode with the same pixel dimensions as your normal
video (see "batch=config" command for how to create fractint.cfg).
Using the "3" command, enter the file name of the saved 256 color
file, say "no" to the "Legal for this machine?" prompt, selecting
instead your 2 or 4 color mode, and answer the other 3D prompts. You
will then see a 3D projection of the fractal. Another example of Stone
Soup responsiveness to our fan mail!
HOW TO MAKE 3D SLIDES
Bruce Goren, CIS's resident stereoscopic maven, contributed these tips
on what to do with your 3D images (Bruce inspired and prodded us so
much we automated much of what follows, allowing both this and actual
on screen stereo viewing, but we included it here for reference and a
brief tutorial.)
"I use a Targa 32 video card and TOPAS graphic software, moving the
viewport or imaginary camera left and right to create two separate
views of the stationary object in x,y,z, space. The distance between
the two views, known as the inter-ocular distance, toe-in or
convergence angle, is critical. It makes the difference between good
3-D and headache-generating bad 3-D.
"For a 3D fractal landscape, I created and photographed the left and
right eye views as if flying by in an imaginary airplane and mounted
the film chips for stereo viewing. To make my image, first I generated
a plasma cloud based on a color map I calculated to resemble a
geological survey map (available on CIS as TARGA.MAP). In the 3D
reconstruction, I used a perspective value of 150 and shifted the
camera -15 and +15 on the X-axis for the left and right views. All
other values were left to the defaults.
"The images are captured on a Matrix 3000 film recorder -- basically a
box with a high-resolution (1400 lines) black and white TV and a 35mm
camera (Konica FS-1) looking at the TV screen through a filter wheel.
The Matrix 3000 can be calibrated for 8 different film types, but so
far I have only used Kodak Ektachrome 64 daylight for slides and a few
print films. I glass mount the film chips myself.
"Each frame is exposed three times, once through each of the red,
blue, and green filters to create a color image from computer video
without the scan-lines which normally result from photographing
television screens. The aspect ratio of the resulting images led me
to mount the chips using the 7-sprocket Busch-European Emde masks.
The best source of Stereo mounting and viewing supplies I know of is
an outfit called Reel 3-D Enterprises, Inc. at P.O. Box 2368, Culver
City, CA 90231, tel. 213-837-2368. "My platform is an IBM PC/AT
crystal-swapped up to 9 MHz. The math co-processor runs on a separate
8-MHz accessory sub-board. The system currently has 6.5 MB of RAM."
INVERSION
Many years ago there was a brief craze for "anamorphic art": images
painted and viewed with the use of a cylindrical mirror, so that they
looked weirdly distorted on the canvas but correct in the distorted
reflection. (This byway of art history may be a useful defense when
your friends and family give you odd looks for staring at fractal
images color-cycling on a CRT.)
The <I>nversion option performs a related transformation on most of the
fractal types. You define the center point and radius of a circle;
FRACTINT maps each point inside the circle to a corresponding point
outside, and vice-versa. This is known to mathematicians as inverting
(or if you want to get precise, "everting") the plane, and is something
they can contemplate without getting a headache. John Milnor, mentioned
earlier in connection with the distance-estimator method, made his name
in the 1950s with a method for everting a seven-dimensional sphere, so
we have a lot of catching up to do.
For example, if a point inside the circle is 1/3 of the way from the
center to the radius, it is mapped to a point along the same radial
line, but at a distance of (3 * radius) from the origin. An outside
point at 4 times the radius is mapped inside at 1/4 the radius.
The <I> command prompts you for the radius and center coordinates of
the inversion circle. A default choice of -1 sets the radius at 1/6 the
smaller dimension of the current screen mode. The default values
for Xcenter and Ycenter use the center of the current screen.
Try this one out with a Newton plot, so its radial "spokes" will give
you something to hang on to. Plot a Newton-method image, then hit <I>
and use a radius of 1, default center coordinates. The center has
"exploded" to the periphery.
Inverting through a circle not centered on the origin produces bizarre
effects that we're not even going to try to describe. Aren't computers
wonderful?
DECOMPOSITION
You'll remember that most fractal types are calculated by iterating a
simple function of a complex number, producing another complex number,
until either the number exceeds some pre-defined "bailout" value, or
the iteration limit is reached. The pixel corresponding to the starting
point is then colored based on the result of that calculation.
The decomposition command toggles to another coloring protocol. (It's
<Q> because the first implementation was 4-way or "quaternary," and <D>
was already spoken for.) Here the points are colored according to which
quadrant of the complex plane (negative real/positive imaginary,
positive real/positive imaginary, etc.) the final value is in. If you
use 4 as the first parameter, points ending up in each quadrant are
given their own color; if 2 (binary decomposition), points in alternat-
ing quadrants are given 2 alternating colors.
The result is a kind of warped checkerboard coloring, even in areas
that would ordinarily be part of a single contour. Remember, for the M-
set all points whose final values exceed 2 (by any amount) after, say,
80 iterations are normally the same color; under decomposition,
FRACTINT runs [bailout-value] iterations and then colors according to
where the actual final value falls on the complex plane.
The second parameter is the bailout value. The smaller it is, the
faster (though not much) the plot will run; the larger it is, the more
accurate it will be. A value of about 50 is a good compromise for M/J
sets.
LOGARITHMIC PALETTES
By default, Fractint uses a continuous palette - ie, if you are using
a 16-color video mode, and you are using the default maximum iteration
count of 150, your image will run through the 16-color palette 150/16 =
9.375 times. If you elect to use Logarithmic palettes, however, the
color Fractint uses for iteration N will be determined by the
algorithm "palettenumber = maxcolors * log(maxiter) / log(N). This
results in spectacularly different images if you are using a high
iteration limit near the current iteration maximum of 32000 and are
zooming in on an area near a "lakelet".
BIOMORPHS
Related to binary decomposition are the "biomorphs" invented by
Clifford Pickover, and discussed by A. K. Dewdney in the July 1989
"Scientific American", page 110. These are so-named because this
coloring scheme makes many fractals look like one-celled animals. The
idea is simple. The escape-time algorithm terminates an iterating
formula when the size of the orbit value exceeds a predetermined
bail-out value. Normally the pixel corresponding to that orbit is
colored according to the iteration when bailout happened. To create
biomorphs, this is modified so that if EITHER the real OR the
imaginary component is LESS than the bailout, then the pixel is set to
the "biomorph" color. The effect is a bit better with higher bailout
values: the bailout is automatically set to 100 when this option is
in effect. You can try other values with the "bailout=" option. The
biomorph option is turned on via the "biomorph=nnn" command-line option
(where "nnn" is the color to use on the affected pixels). When toggling
to Julia sets, the default corners are three times bigger than normal
to allow seeing the biomorph appendages. Does not work with all types -
in particular it fails with any of the mandelsine family. However, if
you are stuck with monochrome graphics, try it - works great in
two-color modes. Try it with the marksmandel and marksjulia types, or
any of the new "biomorph" fractals.
STARFIELDS
Once you have generated your favorite fractal image, you can convert it
into a fractal starfield with the 'a' transformation (for 'astronomy'? -
once again, all of the good letters were gone already). Stars are generated
on a pixel-by-pixel basis - the odds that a particular pixel will coalesce
into a star are based (partially) on the color index of that pixel.
(the following documentation is supplied by Mark Peterson, who wrote the
starfield transformation):
If the screen were entirely black and the 'Star Density per Pixel'
were set to 30 then a starfield transformation would create an evenly
distributed starfield with an average of one star for every 30 pixels.
If you're on a 320x200 screen then you have 64000 pixels and would end
up with about 2100 stars.
By introducing the variable of 'Clumpiness' we can create more stars
in areas that have higher color values. At 100% Clumpiness a color
value of 255 will change the average of finding a star at that
location to 50:50. A lower clumpiness values will lower the amount of
probability weighting. To create a spiral galaxy draw your favorite
spiral fractal (IFS, Julia, or Mandelbrot) and perform a starfield
transformation. For general starfields I'd recommend transforming a
plasma fractal.
Real starfields have many more dim stars than bright ones because very
few stars are close enough to appear bright. To achieve this effect
the program will create a bell curve based on the value of ratio of
Dim stars to bright stars. After calculating the bell curve the curve
is folded in half and the peak used to represent the number of dim stars.
Starfields can only be shown in 256 colors. FRACTINT will automatically
try to load ALTERN.MAP and abort if the map file cannot be found.
3. Command-Line Arguments, Batch Mode, and SSTOOLS.INI
FRACTINT accepts command-line arguments that allow you to load it with
your own choice of video mode, starting coordinates, and just about
every other parameter and option. These arguments can also be included
in a SSTOOLS.INI startup file, or in command files invoked on the
command line using LINK-style syntax ("FRACTINT @MYFILE"). The program
first looks along the DOS PATH for any file called SSTOOLS.INI and
reads start-up variables from that file. Then, it looks at its own
command line; arguments there will over-ride those from the .INI file.
The syntax is:
FRACTINT argument argument argument...
where the individual arguments are separated by one or more spaces (an
individual argument may NOT include spaces). Either upper or lower
case may be used, and arguments can be in any order. To make your file
more readable, you may replace the spaces with Returns.
Some terminology:
COMMAND=nnn enter a number in place of "nnn"
COMMAND=[filename] you supply filename
COMMAND=yes|no|whatever means choose one of "yes", "no", and "whatever"
COMMAND=1st[/2nd[/3rd]] - the slash-separated parameters "2nd" and
"3rd" are optional
FILENAME=[name]
Causes FRACTINT to read the named file, which must either have been
saved from an earlier FRACTINT session (version 7.0 or later) or be a
generic GIF file, and use that as its starting point, bypassing the
initial information screens. The filetype is optional and defaults to
.FRA. Generic GIF files are restored as fractal type "plasma". On the
command line you may omit FILENAME= and just give the name; the full
argument is required in SSTOOLS.INI and other command files.
@FILENAME
Causes FRACTINT to read "filename" for arguments. When it finishes, it
resumes reading its own command line -- i.e., "FRACTINT MAXITER=250
@MYFILE PASSES=1" is legal. This option is only valid on the command
line, as FRACTINT is not clever enough to deal with multiple
indirection.
PASSES=1|2|guess|btm
Selects single-pass, dual-pass, solid-Guessing mode, or the Boundary
Tracing algorithm. Again, the first two take the same total time to
finish the display, while solid-guessing is faster at the risk of
errors for a few pixels. Boundary tracing is sometimes faster,
sometimes slower, and doesn't work for some fractal types at all
(like the Newton fractals).
INSIDE=nnn|bof60|bof61
Set the color of the interior: for example, "INSIDE=0" makes the M-set
a stylish basic black. A setting of -1 makes inside=maxiter. We have
added two more options, inside=bof61 and inside=bof62, which reveal
more of the hidden structure inside the "lake". These options are named
after the figures on pages 61 and 62 of "Beauty of Fractals". See appendix
for a brilliant explanation of what these do!
OUTSIDE=nnn
Set the color of the exterior: for example, "OUTSIDE=1" makes all
points not INSIDE the fractal set to color 1 (blue). Note that
defining an OUTSIDE color forces any image to be a two-color one:
either a point is INSIDE the set, or it's OUTSIDE it.
MAXITER=nnn
Reset the iteration maximum (the number of iterations at which the
program gives up and says 'OK, this point seems to be part of the set
in question and should be colored [insidecolor]') from the default
150. Values range from 10 to 32000 (super-high iteration limits like
30000 are useful when using logarithmic palettes).
ITERINCR=nnn
Set the iteration increment (the change in maxiter when you hit the
'<' or '>' keys). Default is 50.
VIDEO=xxx
Set the initial video mode (and bypass the informational screens).
Handy for batch runs. (Example: VIDEO=F4 for IBM 16-color VGA.)
(You can obtain the current VIDEO= values from the "Video Modes" help
screens inside Fractint. We don't duplicate them here only because
they change so darned often!)
ASKVIDEO=yes|no
If "no," this eliminates the prompt asking you if a file to be
restored is OK for your current video hardware.
WARNING: every version of FRACTINT so far has had a bigger, better, but
shuffled-around video table. Since calling for a mode your hardware
doesn't support can leave your system in limbo, be careful about
leaving these arguments in a command file to be used with future
versions of FRACTINT, particularly for the super-VGA modes.
SAVENAME=[name]
Set the filename to use when you <S>ave a screen. The default filename
is FRACT001. The .FRA extension is optional (Example: SAVENAME=myfile)
WARN=yes|no
Sets the savename warning flag (default is 'no'). If 'yes', saved
files will NOT over-write existing files from previous sessions;
instead the automatic incrementing of FRACTnnn.FRA will continue.
TYPE=[name]
Selects the type of fractal image to display. The default is type
"mandel," the M-set.
PARAMS=n/n/n/n...
Set optional (required, for some fractal types) values used in
plotting. These numbers typically represent the real and imaginary
portions of some startup value, and are described in detail as needed
in Sec. 2. (Example: FRACTINT TYPE=julia PARAMS=-0.48/0.626 would wait
at the opening screen for you to select a video mode, but then proceed
straight to the Julia set for the stated x (real) and y (imaginary)
coordinates.)
CORNERS=xmin/xmax/ymin/ymax
Begin with these coordinates as the range of x and y coordinates,
rather than the default values of (for type=mandel) -2.0/2.0/-1.5/1.5.
(Example: corners=-0.739/-0.736/0.288/0.291).
POTENTIAL=maxcolor[/slope[/modulus[/potfile]]]
Establishes the "continuous potential" coloring mode for all fractal
types except plasma clouds, IFS and IFS3D. The four arguments define
the maximum color value, the slope of the potential curve, the modulus
"bailout" value, and the savefile name. Example: "POTENTIAL=
240/2000/40/potfile". The Mandelbrot and Julia types ignore the
modulus bailout value and use their own hardwired value of 4.0
instead; see Sec. 4 on the continuous-potential algorithm for details.
RSEED=nnnn
The initial random-number "seed" for plasma clouds is taken from your
PC's internal clock-timer. This argument forces a value (which you can
see in the <Tab> display), and allows you to reproduce plasma clouds.
A detailed discussion of why a TRULY random number may be impossible
to define, let alone generate, will have to wait for "FRACTINT: The 3-
MB Doc File."
DECOMP=2|4|8|16|32|64|128|256
Invokes the corresponding decomposition coloring scheme.
LOGMAP=yes Switches the default color palette-map selection from
normal (continu-ous) to logarithmic.
IFS=[filename]
Use the IFS coded values in [filename] to generate Barnsley IFS
fractal images. The default extension is .IFS. See Sec. 2 for details.
IFS3D=[filename]
Use the IFS coded values in [filename] to generate Barnsley IFS3D
fractals.
3D=Yes
Replaces the default answers to the <3> command's prompts, as
described in Sec. 2. If FILENAME= is given, forces the restore to be
performed in 3D mode. Very handy when used with the 'batch=yes' option
for batch-mode 3D images. (Note: the form "3D/=parm/parm/parm ..." for
entering 3D parameters still works but will not be supported in the
future. Use the variables below. Position-sensitive parameters are
nasty and evil, especially when there are dozens of them!)
The options below replace selected 3D defaults:
sphere=yes Turns on spherical projection mode
Longitude=nn/nn Longitude minimum and maximum
latitude=nn/nn Latitude minimum and maximum
radius=nn Radius scale factor
rotation=nn[/nn[/nn]] Rotation about x,y, and z axes
scalexyz=nn/nn/nn X,y,and z scale factors
roughness=nn Same as z scale factor
waterline=nn Colors nn and below will be "inside" color
filltype=nn 3D filltype
perspective=nn Perspective distance
xyshift=nn/nn Shift image in x and y directions with
perspective
lightsource=nn/nn/nn Coordinates for light-source vector
smoothing=nn Smooths images in light-source fill modes
transparent=min/max Defines a range of colors to be treated as
"transparent" when <O>verlaying 3D images.
xyadjust=nn/nn This shifts the image in the x/y dir without
perspective
stereo=n Selects the type of stereo image creation
interocular=nn Sets the interocular distance for stereo
converge=nn Determines the overall image separation
crop=nn/nn/nn/nn Trims the edges off stereo pairs
bright=nn/nn Compensates for funny glasses filter parameters
To stay out of trouble, use the complete list, even if you want to use
what you think are the default values. It takes a little practice to
learn what the default values really are. The best way to create a
command file is to use the Batch command <B> on an image you like and
then modify the resulting parameters.
INVERT=nn/nn/nn
Turns on inversion. The parameters are radius of inversion, x-coordi-
nate of center, and y-coordinate of center. -1 as the first parameter
sets the radius to 1/6 the smaller screen dimension; no x/y parameters
defaults to center of screen. The values are displayed with the <Tab>
command.
FLOAT=yes
Most fractal types have both a fast integer math and a floating
point version. The faster, but possibly less accurate, integer
version is the default. If you have a new 80486 or other fast
machine with a math coprocessor, or if you are using the
continuous potential option (which looks best with high bailout
values not possible with our integer math implementation), you
may prefer to use floating point. Just add "float=yes" to the
command line to do so.
PRINTER=type[/resolution[/port#]]
Defines your printer setup. Currently legal printer types (only the
first two characters are needed): [HP] LaserJet, [EP]son-compatible,
[IB]M-compatible (which is identical to the Epson driver at the
moment), and [CO]lor (equivalent to the Star Micronics printer).
The default printer type is the Epson/IBM. Resolution is in
DPI, and currently available values are 60, 120, and 240 for the
Epson/IBM and 75, 150, and 300 for the LaserJet (the default value is
the lowest resolution). Legal printer port values are 1, 2, and 3 (for
LPT 1-3) and 11, 12, 13, and 14 (for COM1-4). The SSTOOLS.INI file is a
REAL handy place to put this option, so that it's available whenever
you have that sudden, irresistible urge for hard copy.
CYCLELIMIT=nnn
Sets the speed of color cycling. Technically, the number of DAC regis-
ters updated during a single vertical refresh cycle. Legal values are 1
- 256, default is 55.
MAP=[filename]
Reads in a replacement color map from [filename]. This map replaces the
default video color map of your VGA or TARGA card. The file must be in
the format described in Sec. 4. The difference between this argument
and an alternate map read in via <M> in color-command mode is that this
one is permanent. WARNING: If colors 0 and 1 decode to the same color,
your <H>elp screens will use the same color for both text and back-
ground, which makes them kind of difficult to read.
RAMVIDEO=no
If set, when you select a "Disk/RAM" video mode, the check for adequate
RAM is bypassed, and Fractint heads straight for your expanded memory
and/or hard disk. This is useful where you may *technically* have
enough RAM for a particular video mode, but you may want to use it
later for something else (like shelling to DOS).
FORMULAFILE=[formulafilename]
Lets you specify the default formula file for type=formula fractals
(the default is FRACTINT.FRM). Handy if you want to generate one
of these fractal types in batch mode.
FORMULANAME=[formulaname]
Lets you specify the default formula name for type=formula fractals
(the default is no formula at all). Required if you want to generate
one of these fractal types in batch mode, as this is the only way to
specify a formula name in that case.
;
As usual, indicates the rest of the command line (or the rest of the
individual line inside command files) is a comment.
SOUND=off|x|y|z
We're all MUCH too busy to waste time with FRACTINT at work, and no
doubt you are too, so "sound=off" included only for use at home, to avoid
waking the kids or your Significant Other, late at night. (By the way,
didn't you tell yourself "just one more zoom on LambdaSine" an hour
ago?) Suggestions for a "boss" hot-key will be cheerfully ignored, as
this sucker is getting big enough without including a spreadsheet
screen too. The "sound=x/y/x" options are for the "attractor"
fractals, like the Lorenz fractals - they play with the sound on your
PC speaker as they are generating an image, based on the X or Y or Z
co-ordinate they are displaying at the moment. At the moment,
"sound=x" (or y or z) really doesn't work very well when using an
integer algorithm - try it with the floating-point toggle set, instead.
HERTZ=nnn
Adjusts the sound produced by the "sound=x/y/z" option. Legal values
are 200 through 10000.
BATCH MODE
Two other arguments have special uses. It IS possible, believe it or
not, to become so jaded with the screen drawing process, so familiar
with the types and options, that you just want to hit a key and do
something else until the final images are safe on disk. It's
especially possible if you use <Tab> to note parameters for interesting
areas, or <B> to store them as lines in FRABATCH.BAT.
BATCH=yes
Run in batch mode -- that is, FRACTINT acts as if you had hit <S> to
save the image after drawing it (using defaults or whatever other
parameters you use here or in a command file), followed by exit to DOS.
The "VIDEO=" mode option is required.
BATCH=config
Starts a quick batch-mode run that creates a default FRACTINT.CFG file
from the full internal video table (FRACTINT.CFG is described in Sec.
5).
SSTOOLS.INI
If you are familiar with Microsoft's TOOLS.INI or WINDOWS.INI configu-
ration files, the SSTOOLS.INI command file is used in the same way. In
particular, you designate a section of SSTOOLS.INI as belonging to a
particular program by beginning the section with a label in brackets.
FRACTINT looks for the label [fractint], and ignores any lines it finds
in the file belonging to any other label. If an SSTOOLS.INI file looks
like this:
[fractint]
sound=off ; (for home use only)
printer=hp ; my printer is a LaserJet
[startrek]
Aye, captain, but I dinna think the engines can take it!
[fractint]
inside=0 ; using "traditional" black
FRACTINT will use only the second, third, and last lines.
(Why use a convention like that when FRACTINT is the only program
you know of that uses an SSTOOLS.INI file? Because there are other
programs (such as Lee Crocker's PICLAB) that now use the same file, and
people working on other, sister programs to FRACTINT are going to read
that file. And just when you thought it was safe to download again..!)
4. File Formats, Color Maps and All That
FRACTINT AND .GIF FILES
Since version 5.0, FRACTINT has had the <S>ave-to-disk command, which
stores screen images in the extremely compact, flexible .GIF (Graphics
Interchange Format) widely supported on Compuserve. Version 7.0 added
the <R>estore-from-disk capability. Unfortunately, this creates a
problem. The current official .GIF specification does not offer a place
to store the small amount of extra information that FRACTINT needs in
order to implement the <R> feature -- i.e., the parameters that let you
keep zooming, etc. so on as if the restored file had just been created
in this session.
FRACTINT gets around this restriction in a non-standard manner, saving
its application-specific information AFTER the official GIF terminator
character. This trick works with all of the popular GIF decoders that
we have tested (although some of them require renaming the file to
xxxx.GIF first).
We are not, however, claiming that these files are true .GIF files. For
one thing, information after the .GIF terminator has the potential to
confuse the on-line .GIF viewers used on Compuserve. For another, it is
the opinion of some .GIF developers that the addition of this extra
information violates the GIF spec. That's why we use the default
filetype .FRA instead.
If you wish to save FRACTINT images as true .GIF files, simply specify
.GIF as the extension in the SAVENAME argument ("SAVENAME=
somename.gif"). FRACTINT will detect the extension and drop the extra
data. You will NOT be able to fully restore such files with <R>,
because the information FRACTINT needs just isn't there. When the <R>
command encounters true .GIF files (whether FRACTINT created them or
not), it does the best it can and restores them as if they were un-
zoomable plasma clouds.
An easy way to convert an existing .FRA file into true .GIF format
suitable for uploading is something like this at the DOS prompt:
FRACTINT MYFILE SAVENAME=MYFILE.GIF BATCH=YES
FRACTINT will load MYFILE.FRA, save it in true .GIF format as
MYFILE.GIF, and return to DOS.
Note that the .GIF spec is constantly being reviewed, and it's entirely
possible that future enhancements will provide a standard way to store
application-specific information. We intend to use any such extensions
in an upward-compatible manner if and when they become available.
GIF and "Graphics Interchange Format" are trademarks of Compuserve
Incorporated, an H&R Block Company.
CONTINUOUS POTENTIAL
FRACTINT's images are usually calculated by the "level set" method,
producing bands of color corresponding to regions where the calculation
gives the same value. When viewed in 3D, most images other than plasma
clouds are like terraced landscapes: most of the surface is either
horizontal or vertical.
To get the best results with the "illuminated" 3D fill options 5 and 6,
there is an alternative approach that yields continuous changes in
colors. A 256-color MCGA/VGA video mode is mandatory to appreciate this
effect (it's hard to show continuous variation with only 4 or 16
colors!)
Continuous potential is approximated by calculating
potential = log(modulus)/2^iterations
where "modulus" is the orbit value (magnitude of the complex number)
when the modulus bailout was exceeded, at the "iterations" iteration.
Clear as mud, right?
Fortunately, you don't have to understand all the details. However,
there ARE a few points to understand. First, FRACTINT's criterion for
halting a fractal calculation, the "modulus bailout value", is general-
ly set to 4. Continuous potential is inaccurate at such a low value.
The bad news is that the integer math which makes the "mandel" and
"julia" types so fast imposes a hard-wired maximum value of 127. You
can still make interesting images from those types, though, so don't
avoid them. You will see "ridges" in the "hillsides." Some folks like
the effect.
The good news is that the other fractal types, particularly the
(generally slower) floating point algorithms, have no such limitation.
The even better news is that there is a floating-point algorithm for
the "mandel" and "julia" types. To force the use of a floating-point
algorithm, use Fractint with the "FLOAT=YES" command-line toggle. Only
a few fractal types like plasma clouds, the Barnsley IFS/IFS3d types,
and "test" are unaffected by this toggle.
The parameters for continuous potential are:
potential=maxcolor[/slope[/modulus[/potfile]]]
"Maxcolor" is the color corresponding to zero potential, which plots as
the TOP of the mountain. Generally this should be set to one less than
the number of colors, e.g. 255 for VGA. Remember that the last few
colors of the default IBM VGA palette are BLACK, so you won't see what
you are really getting unless you change to a different palette.
"Slope" affects how rapidly the colors change -- the slope of the
"mountains" created in 3D. If this is too low, the palette will not
cover all the potential values and large areas will be black. If it is
too high, the range of colors in the picture will be much less than
those available. There is no easy way to predict in advance what these
values should be.
"Modulus" is the bailout value used to determine when an orbit has
"escaped". Larger values give more accurate and smoother potential. A
value of 500 gives excellent results. As noted, this value must be
<128 for the integer fractal types (if you select a higher number, they
will use 127).
"Potfile" is a filename to store the potential image in compressed
TARGA format, with 16 bits per pixel. If you save the image in the
normal way and then view it in 3D, the illumination modes 5 and 6 will
work fine, but the colors will look a bit granular. This is because
even with 256 colors, the continuous potential is being truncated to
integers. If the "potfile" parameter is given, much smoother pictures
can be obtained. But beware: even these compressed files still use up
to 2 bytes per pixel, so they can get quite large.
The following commands can be used to recreate the image that Mark
Peterson first prototyped for us, and named "MtMand":
TYPE=mandel
CORNERS=-0.19920/-0.11/1.0/1.06707
INSIDE=255
MAXITER=255
POTENTIAL=255/2000/1000/potfile.tga
PASSES=1
FLOAT=yes
This assumes a 256-color video mode.
PALETTE MAPS
If you have a VGA, Super-VGA, 8514/A, or TARGA video adapter, you can
save and restore your color palette using special color-map files
and either the command-line "map=" option, or the "D", "A", "S",
and "M" color-cycling mode commands. These color-maps are ASCII files
set up as a series of RGB triplet values (one triplet per line,
encoded as the red, green, and blue [RGB] components of the color).
Note that the color values are in TARGA/GIF format - values go from
0 (low) to 255 (high), so for a VGA adapter they get divided by 4
before being stuffed into the VGA's Video-DAC registers (so '6'
and '7' end up referring to the same color value). The default
filetype for color-map files is ".MAP".
The distribution file contains sample .MAP files for you to examine
and modify - DEFAULT.MAP (the VGA start-up values), ALTERN.MAP
(the famous "Peterson-Vigneau Pseudo-Grey Scale"), GAMMA1.MAP and
GAMMA2.MAP (Lee Crocker's response to ALTERN.MAP), and LANDSCAP.MAP
Guruka Singh Khalsa's favorite color-map for plasma "landscapes").
5. Hardware Support
True to the spirit of public-domain programming, FRACTINT makes only a
limited attempt to verify that your video adapter can run in the mode you
specify, or even that an adapter is present, before writing to it.
Hence the warning to check your "VIDEO=" argument before using a new
version, in which the old key combo may now call an ultraviolet holo-
graphic mode.
FRACTINT also assumes that every EGA adapter has a full 256K of memory
(and can therefore display 640 x 350 x 16 colors), but does nothing to
verify that fact before slinging pixels.
NOTES ON MODES, "STANDARD" AND OTHERWISE
FRACTINT uses a video adapter table in the "C" program for everything
it needs to know about any particular adapter/mode combination. This
table can contain information for up to 98 adapter/mode combinations,
and is automatically tied to 84 keys (F2-F10, their Control/ Shift/Alt
variants, and many Alt-x keypad combos) when the program is running.
The table entries, and the function keys they are tied to, are dis-
played as part of the help screens.
This table makes adding support for various third-party video cards and
their modes much easier, at least for the ones that pretend to be a
standard adapter with more dots and/or colors. There is even a special
"roll-your-own" video mode (mode 19) enabling those of you with "C"
compilers and a copy of the FRACTINT source to generate video modes
supporting whatever adapter you may have. You can customize the table
using the external configuration file FRACTINT.CFG, described below.
The table as currently distributed begins with nine standard and
several non-standard IBM video modes that have been exercised success-
fully with a PS/2 model 80. These entries, coupled with the descriptive
comments in the table definition and the information supplied (or that
should have been supplied!) with your video adapter, should be all you
need to add your own entries.
320 x 400 x 256 and 360 x 480 x 256 VGA MODES
The IBM VGA adapter is a highly programmable device, and can be set up
to display many video-mode combinations beyond those "officially"
supported by the IBM BIOS. These video modes are perfectly legal, but
temporarily reprogram the adapter (IBM or fully register-compatible) in
a non-standard manner that the BIOS does not recognize. Because of
this, the program cannot send any text to the screen while it is in one
of these modes (the BIOS would garbage it). An internal flag inhibits
all text output while the screen is in one of these video modes.
FRACTINT's <H> and <Tab> commands still work, because they temporarily
switch the screen to an alternate video mode.
8514/A MODES
The IBM 8514/A modes use IBM's software interface, and require the pre-
loading of IBM's HDIDLOAD TSR utility. There are two sets of 8514/A
modes: full sets (640x480, 1024x768) which cover the entire screen and
do NOT have a border color (so that you cannot tell when you are
"paused" in a color-cycling mode), and partial sets (632x474, 1016x762)
with small border areas which do turn white when you are paused in
color-cycling mode. Also, while these modes are declared to be 256-
color, if you do not have your 8514/A adapter loaded with its full
complement of memory you will actually be in 16-color mode. Finally,
because IBM's interface does not handle drawing single pixels very well
(we have to draw a 1x1 pixel "box"), generating the zoom box is excru-
ciatingly slow. Still, it works!
SUPER-EGA AND SUPER-VGA MODES
After the IBM and quasi-pseudo-demi-IBM modes, the table contains an
ever-increasing number of entries for other adapters. Almost all of
these entries have been added because someone like you sent us spec
sheets, or modified FRACTINT to support them and then informed us about
it. With version 12.0, we've added both John Bridges' SuperVGA
Autodetecting logic *and* VESA adapter detection, so that many of the
brand-specific SuperVGA modes have been collapsed into a single function
key. There is now exactly one function key for SuperVGA 640x480x256
mode, for instance.
TARGA MODES
TARGA support for FRACTINT is provided courtesy of Joe McLain. Be aware
that there are a LOT of possible TARGA configurations, and a LOT of
opportunities for a TARGA board and a VGA or EGA board to interfere
with each other, and we may not have all of them smoothed away yet.
Also, the TARGA boards have an entirely different color-map scheme than
the VGA cards, and at the moment they cannot be run through the color-
cycling menu. The "MAP=" argument (Sec. 3), however, works with both
TARGA and VGA boards and enables you to redefine the default color maps
with either board.
"RAM-VIDEO" AND "DISK-VIDEO" MODES
These "video modes" do not involve a video adapter at all. They use
either your spare RAM (if you have enough), your spare expanded memory
(if you have it, and have enough of it), or your disk drive (as file
FRACTINT.DSK) to store the fractal image. These modes are useful for
creating images beyond the capacity of your video adapter, right up to
the current internal limit of 2048 x 2048 x 256, and for background
processing under multi-tasking DOS managers such as DESQview.
The zoom box is disabled during these modes (you couldn't see where it
is anyway). To eliminate thrashing, if your "video" is really on a hard
disk, so are features such as orbit display, dual-pass mode,
solid-guessing, symmetry checks and (sorry) plasma clouds that require
simultaneous access to several lines of the "display.".
On a PC with 640K of memory running only FRACTINT under DOS, "disk-
video" modes up to 640x480x256 fit into RAM, and any higher-resolution
modes end up going to expanded memory or disk. While you are in these
modes, your screen will display text information that lets you know
whether you are using your RAM or your disk drive and what portion of
the "screen" is being read from or written to.
"TWEAKED" VGA MODES
FRACTINT contains code that sets up the IBM (or any truly register-
compatible) VGA adapter for several extended modes such as 704x528,
736x552, 768x576, and 800x600. It does this by programming the VGA
controller to use the fastest dot-clock on the IBM adapter (28.322
MHz), throwing more pixels, and reducing the refresh rate to make up
for it.
These modes push many monitors beyond their rated specs, in terms of
both resolution and refresh rate. Signs that your monitor is having
problems with a particular "tweaked" mode include:
* vertical or horizontal overscan (displaying dots beyond the edges of
your visible CRT area)
* flickering (caused by a too-slow refresh rate)
* vertical roll or total garbage on the screen (your monitor simply
can't keep up, or is attempting to "force" the image into a pre-set
mode that doesn't fit).
We have successfully tested the modes up to 768x576 on an IBM PS/2
Model 80 connected to IBM 8513, IBM 8514, NEC Multisync II, and Zenith
1490 monitors (all of which exhibit some overscan and flicker at the
highest rates), and have tested 800x600 mode on the NEC Multisync II
(although it took some twiddling of the vertical-size control).
FRACTINT.CFG
If you have a favorite adapter/video mode that you would like to add to
FRACTINT... if you want to remove table entries that do not apply to
your system... if you're bothered that your favorite mode requires the
<Alt><Left-Shift><Swizzlestick> key combination... or if you are using
a non-enhanced keyboard so that you can't USE that combination...
relief is here, and without even learning "C"!
FRACTINT will create an external, editable video configuration file
called FRACTINT.CFG, and from then on will use that instead of its
internal table as long as it can locate it somewhere along the DOS
path. Enter FRACTINT BATCH=CONFIG, and you will get a default file with
an entry for every one of the internal video table entries, and you can
go to work on it with a text editor.
Any line in the file that begins with a tab or a space (or is empty) is
treated as a comment. The rest of the lines must consist of ten fields
separated by commas. The ten fields are defined as:
1. The name of the adapter/video mode (25 chars max, no leading
blanks). The adapter is set up for that mode via INT 10H, with:
2. AX = this,
3. BX = this,
4. CX = this, and
5. DX = this (hey, having all these registers wasn't OUR idea!)
6. An encoded value describing how to write to your video memory in
that mode. Currently available codes are:
1) Use the BIOS (INT 10H, AH=12/13, AL=color) (last resort - SLOW!)
2) Pretend it's a (perhaps super-res) EGA/VGA
3) Pretend it's an MCGA
4) SuperVGA 256-Color mode using the Tseng Labs chipset
5) SuperVGA 256-Color mode using the Paradise chipset
6) SuperVGA 256-Color mode using the Video-7 chipset
7) Non-Standard IBM VGA 360 x 480 x 256-Color mode
8) SuperVGA 1024x768x16 mode for the Everex chipset
9) TARGA video modes
10) HERCULES video mode
11) Non-Video [disk or RAM] "video"
12) 8514/A video modes
13) CGA 320x200x4-color and 640x200x2-color modes
14) Reserved for Tandy 1000 video modes
15) SuperVGA 256-Color mode using the Trident chipset
16) SuperVGA 256-Color mode using the Chips & Tech chipset
17) SuperVGA 256-Color mode using the ATI VGA Wonder chipset
18) SuperVGA 256-Color mode using the EVEREX chipset
19) Roll-your-own video mode (as you've defined it in YOURVID.C)
20) SuperVGA 1024x768x16 mode for the ATI VGA Wonder chipset
21) SuperVGA 1024x768x16 mode for the Tseng Labs chipset
22) SuperVGA 1024x768x16 mode for the Trident chipset
23) SuperVGA 1024x768x16 mode for the Video 7 chipset
24) SuperVGA 1024x768x16 mode for the Paradise chipset
25) SuperVGA 1024x768x16 mode for the Chips & Tech chipset
26) SuperVGA 1024x768x16 mode for the Everex Chipset
27) SuperVGA Auto-Detect mode (we poke around looking for your adapter type)
28) VESA modes
7. The number of pixels across the screen (X - 160 to 2048)
8. The number of pixels down the screen (Y - 160 to 2048)
9. The number of available colors (2, 4, 16, or 256)
10. A comment describing this mode (25 chars max, leading blanks are OK)
NOTE that the AX, BX, CX, and DX fields are generated (and read back)
using hexadecimal notation (fifteen ==> 'f', sixteen ==> '10'), because
that's the way most adapter documentation describes it. The other
fields use standard decimal notation.
If you look closely at the default entries, you will notice that the
IBM VGA entries labeled "tweaked" and "non standard" have entries in
the table with AX = BX = CX = 0, and DX = some other number. Those are
special flags that we used to tell the program to custom-program the
VGA adapter, and are NOT undocumented BIOS calls. Maybe they should be,
but they aren't.
If you have a fancy adapter and a new video mode that works on it, and
it is not currently supported, PLEASE GET THAT INFORMATION TO US! We
will add the video mode to the list on our next release, and give you
credit for it. Which brings up another point: If you can confirm that a
particular video adapter/mode works (or that it doesn't), and the
program says it is UNTESTED, please get that information to us also.
Thanks in advance!
6. Fractals and the PC
A LITTLE HISTORY
Like new forms of life, new branches of mathematics and science don't
appear from nowhere. The ideas of fractal geometry can be traced to the
late nineteenth century, when mathematicians created shapes -- sets of
points -- that seemed to have no counterpart in nature. By a wonderful
irony, the "abstract" mathematics descended from that work has now
turned out to be MORE appropriate than any other for describing many
natural shapes and processes.
Perhaps we shouldn't be surprised. The Greek geometers worked out the
mathematics of the conic sections for its formal beauty; it was two
thousand years before Copernicus and Brahe, Kepler and Newton overcame
the preconception that all heavenly motions must be circular, and found
the ellipse, parabola, and hyperbola in the paths of planets, comets,
and projectiles.
In the 17th century Newton and Leibniz created calculus, with its
techniques for "differentiating" or finding the derivative of functions
-- in geometric terms, finding the tangent of a curve at any given
point. True, some functions were discontinuous, with no tangent at a
gap or an isolated point. Some had singularities: abrupt changes in
direction at which the idea of a tangent becomes meaningless. But these
were seen as exceptional, and attention was focused on the "well-
behaved" functions that worked well in modeling nature.
Beginning in the early 1870s, though, a 50-year crisis transformed
mathematical thinking. Weierstrass described a function that was
continuous but nondifferentiable -- no tangent could be described at
any point. Cantor showed how a simple, repeated procedure could turn a
line into a dust of scattered points, and Peano generated a convoluted
curve that eventually touches every point on a plane. These shapes
seemed to fall "between" the usual categories of one-dimensional lines,
two-dimensional planes and three-dimensional volumes. Most still saw
them as "pathological" cases, but here and there they began to find
applications.
In other areas of mathematics, too, strange shapes began to crop up.
Poincare attempted to analyze the stability of the solar system in the
1880s and found that the many-body dynamical problem resisted tradi-
tional methods. Instead, he developed a qualitative approach, a "state
space" in which each point represented a different planetary orbit, and
studied what we would now call the topology -- the "connectedness" --
of whole families of orbits. This approach revealed that while many
initial motions quickly settled into the familiar curves, there were
also strange, "chaotic" orbits that never became periodic and predict-
able.
Other investigators trying to understand fluctuating, "noisy" phenomena
-- the flooding of the Nile, price series in economics, the jiggling of
molecules in Brownian motion in fluids -- found that traditional models
could not match the data. They had to introduce apparently arbitrary
scaling features, with spikes in the data becoming rarer as they grew
larger, but never disappearing entirely.
For many years these developments seemed unrelated, but there were
tantalizing hints of a common thread. Like the pure mathematicians'
curves and the chaotic orbital motions, the graphs of irregular time
series often had the property of self-similarity: a magnified small
section looked very similar to a large one over a wide range of scales.
WHO IS THIS GUY, ANYWAY?
While many pure and applied mathematicians advanced these trends, it is
Benoit Mandelbrot above all who saw what they had in common and pulled
the threads together into the new discipline.
He was born in Warsaw in 1924, and moved to France in 1935. In a time
when French mathematical training was strongly analytic, he visualized
problems whenever possible, so that he could attack them in geometric
terms. He attended the Ecole Polytechnique, then Caltech, where he
encountered the tangled motions of fluid turbulence.
In 1958 he joined IBM, where he began a mathematical analysis of
electronic "noise" -- and began to perceive a structure in it, a
hierarchy of fluctuations of all sizes, that could not be explained
by exiting statistical methods. Through the years that followed, one
seemingly unrelated problem after another was drawn into the growing
body of ideas he would come to call fractal geometry.
As computers gained more graphic capabilities, the skills of his mind's
eye were reinforced by visualization on display screens and plotters.
Again and again, fractal models produced results -- series of flood
heights, or cotton prices -- that experts said looked like "the real
thing."
Visualization was extended to the physical world as well. In a provoc-
ative essay titled "How Long Is the Coast of Britain?" Mandelbrot noted
that the answer depends on the scale at which one measures: it grows
longer and longer as one takes into account every bay and inlet, every
stone, every grain of sand. And he codified the "self-similarity"
characteristic of many fractal shapes -- the reappearance of geometri-
cally similar features at all scales.
First in isolated papers and lectures, then in two editions of his
seminal book, he argued that many of science's traditional mathematical
models are ill-suited to natural forms and processes: in fact, that
many of the "pathological" shapes mathematicians had discovered genera-
tions before are useful approximations of tree bark and lung tissue,
clouds and galaxies.
Mandelbrot was named an IBM Fellow in 1974, and continues to work at
the IBM Watson Research Center. He has also been a visiting professor
and guest lecturer at many universities.
A LITTLE CODE
PERIODICITY LOGIC: The "Mandelbrot Lake" in the center of the M-set
images is the traditional bane of plotting programs. It sucks up the
most computer time because it always reaches the iteration limit -- and
yet the most interesting areas are invariably right at the edge the
lake.
Thanks to Mark Peterson for pointing out (well, he more like beat us
over the head until we paid attention) that the iteration values in the
middle of Mandelbrot Lake tend to decay to periodic loops (i.e., Z(n+m)
== Z(n), a fact that is pointed out on pages 58-61 of "The Beauty of
Fractals"). An intelligent program (like the one he wrote) would check
for this periodicity once in a while, recognize that iterations caught
in a loop are going to max out, and bail out early.
For speed purposes, the current version of the program turns this
checking algorithm on only if the last pixel generated was in the lake.
(The checking itself takes a small amount of time, and the pixels on
the very edge of the lake tend to decay to periodic loops very slowly,
so this compromise turned out to be the fastest generic answer).
Try a full M-set plot with a 1000-iteration maximum with any other
program, and then try it on this one for a pretty dramatic proof of the
value of periodicity checking.
You can get a visual display of the periodicity effects if you press
<O>rbits while plotting. This toggles display of the intermediate
iterations during the generation process. It also gives you an idea of
how much work your poor little PC is going through for you! If you use
this toggle, it's best to disable solid-guessing first using <1> or
<2> because in its second pass, solid-guessing bypasses many of the
pixel calculations precisely where the orbits are most interesting.
Mark was also responsible for pointing out that 16-bit integer math was
good enough for the first few levels of M/J images, where the round-off
errors stay well within the area covered by a single pixel. FRACTINT
now uses 16-bit math where applicable, which makes a big difference on
non-32-bit PCs.
LIMITATIONS OF INTEGER MATH (and how we now get around it)
By default, FRACTINT uses 16-bit and/or 32-bit integer math to generate
nearly all its fractal types. The advantage of integer math is speed: this
is by far the fastest such plotter that we have ever seen on any PC. The
disadvantage is an accuracy limit. Integer math represents numbers like
1.00 as 32-bit integers of the form [1.00 * (2^29)] (approximately
500,000,000 digits!) for the Mandelbrot and Julia sets. Other integer
fractal types use a bitshift of 24 rather than 29, so 1.0 is stored
internally as [1.00 * (2^*24)]. This yields accuracy of better than 8
significant digits, and works fine... until the initial values of the
calculations on consecutive pixels differ only in the ninth decimal
place.
At that point, if Fractint has a floating-point algorithm handy for
that particular fractal type (and virtually all of the fractal types
have one these days), it will silently switch over to the
floating-point algorithm and keep right on going. Fair warning -
if you don't have an FPU, the effect is that of a rocket sled hitting
a wall of jello, and even if you do, the slowdown is noticable.
If it has no floating-point algorithm, FRACTINT does the best it can:
it switches to its minimal drawing mode, with adjacent pixels having
initial values differing by 1 (really 0.000000002), and disables zooming
and panning. If you are stuch with an integer algorithm, you can reach
minimal mode with your fifth consecutive "maximum zoom", each of which
covers about 0.25% of the previous screen. By then your full-screen image
is an area less than 1/(10^13)th [~0.0000000000001] the area of the
initial screen.
Think of it this way: at minimal drawing mode, your VGA display
would have to have a surface area of over one million square miles just
to be able to display the entire M-set using the integer algorithms.
Using the floating-point algorithms, your display would have to
be big enough to fit the entire solar system out to the orbit of
Saturn inside it. So there's a considerable saving on hardware,
electricity and desk space involved here. Also, you don't have to
take out asteroid insurance.
THE FRACTINT "FRACTAL ENGINE" ARCHITECTURE
Several of the authors would never ADMIT this, but FRACTINT has
evolved a powerful and flexible architecture that makes adding
new fractals very easy. (They would never admit this because they
pride themselves on being the sort that mindlessly but happily
hacks away at code and "sees if it works and doesn't hang the
machine".)
Many fractal calculations work by taking a rectangle in the
complex plane, and, point by point, calculating a color
corresponding to that point. Furthermore, the color calculation
is often done by iterating a function over and over until some
bailout condition is met.
In implementing such a scheme, there are three fractal-specific
calculations that take place within a framework that is pretty
much the same for them all. Rather than copy the same code over
and over, we created a standard fractal engine that calls three
functions that may be bolted in temporarily to the engine. The
"bolting in" process uses the C language mechanism of variable
function pointers.
These three functions are:
1) a setup function that is run once per image, to do any
required initialization of variables,
2) a once-per-pixel function that does whatever
initialization has to be done to calculate a color for one
pixel, and
3) a once-per-orbit-iteration function, which is the
fundamental fractal algorithm that is repeatedly iterated in
the fractal calculation.
The common framework that calls these functions can contain all
sorts of speedups, tricks, and options that the fractal
implementor need not worry about. All that is necessary is to
write the three functions in the correct way, and BINGO! - all
options automatically apply. What makes it even easier is that
usually one can re-use functions 1) and 2) written for other
fractals, and therefore only need to write function 3).
Then it occurred to us that there might be more than one sort of
fractal engine, so we even allowed THAT to be bolted in. And we
created a data structure for each fractal that includes pointers
to these four functions, various prompts, a default region of the
complex plane, and various miscellaneous bits of information that
allow toggling between Julia and Mandelbrot or toggling between
the various kinds of math used in implementation.
That sounds pretty flexible, but there is one drawback - you have
to be a C programmer and have a C compiler to make use of it! So
we took it a step further, and designed a built-in high level
compiler, so that you can enter the formulas for the various
functions in a formula file in a straight-forward algebra-like
language, and FRACTINT will compile them and bolt them in for
you!
There is a terrible down side to this flexibility. FRACTINT
users everywhere are going beserk. Fractal-inventing creativity
is running rampant. Proposals for new fractal types are clogging
the mail and the telephones.
All we can say is that non-productivity software has never been
so potent, and we're sorry, it's our fault!
FRACTINT was compiled using Microsoft C 5.1 and Microsoft Assembler 5.1
using the "Medium" model. Note that the assembler code uses the "C"
model option added to version 5.1, and must be assembled with the /MX
switch to link with the "C" code. Because it has become too large to
distribute comfortably as a single compressed file, and because many
downloaders have no intention of ever modifying it, it is now distrib-
uted as two files: one containing FRACTINT.EXE, auxiliary files and
this document, and another containing complete source code (including a
.MAK file and MAKEFRAC.BAT).
APPENDIX A:
MATHEMATICS OF THE FRACTAL TYPES
Fractal Type(s) Formula(s) used
----------------------- ---------------------------------------------
Mandel, Julia Z(n+1) = Z(n)^2 + C
Newton, Newtbasin (roots of) Z^n - 1, wnere n is an integer
ComplexNewton, ComplexBasin (roots of) Z^a - b, where a,b are complex
plasma (see the Plasma section for details)
Mandelsine, Lambdasine Z(n+1) = Lambda * sine(Z(n)) + C
Mandelcos, Lambdacos Z(n+1) = Lambda * cos(Z(n)) + C
Mandelexp, Lambdaexp Z(n+1) = Lambda * exp(Z(n)) + C
Mandelsinh, Lambdasinh Z(n+1) = Lambda * sinh(Z(n)) + C
Mandelcosh, Lambdacosh Z(n+1) = Lambda * cosh(Z(n)) + C
BarnsleyM1, BarnsleyJ1 Z(n+1) = (Z(n)-1) * C if Real(z) >= 0
else (Z(n)+1) * modulus(C)/C
BarnsleyM2, BarnsleyJ2 Z(n+1) = (Z(n)-1) * C if Real(Z(n))*Imag(C)
+Real(C)*Imag(Z(n)) >= 0
else (Z(n)+1) * C
BarnsleyM3, BarnsleyJ3 Z(n+1) = (Real(Z(n))^2 - Imag(Z(n))^2 - 1)
+ i * (2 * Real(Z((n)) * Imag(Z((n)))
if Real(Z(n) > 0
else (Real(Z(n))^2 - Imag(Z(n))^2 - 1
+ lambda * Real(Z(n))
+ i * (2 * Real(Z((n)) * Imag(Z((n))
+ lambda * Real(Z(n))
Sierpinski Z(n+1) = (2x, 2y - 1) if y > .5
else (2x - 1, 2y) if x > .5
else (2X, 2y)
MandelLambda, Lambda Z(n+1) = (C) * (Z(n)^2) + C
MarksMandel, MarksJulia Z(n+1) = (C^(Period-1)) * (Z(n)^2) + C
("Period" is a parameter)
Cmplxmarksmand,Cmplxmarksjul Same as MarksMandel and MarksJulia except period
parameter is complex rather than real
Unity (see the Unity section for details)
ifs, ifs3D (see the IFS section for details)
Mandel4, Julia4 Z(n+1) = Z(n)^4 + C
Test (as distributed, as simple Mandelbrot fractal)
Mansinzsqrd, Julsinzsqrd Z(n+1) = Z(n)^2 + sin(Z(n)) + C
Manzpower, Julzpower Z(n+1) = Z(n)^M + C (M is a parameter)
Mandel4/Julia4 Special case of manzpower and julzpower (M=4)
Manzzpwr, Julzzpwr Z(n+1) = Z(n)^Z(n) + Z(n)^M + C
Mansinexp, Julsinexp Z(n+1) = sin(Z(n)) + e^(Z(n)) + C
popcorn Z(n+1) = x(n+1) + i * y(n+1), where
x(n+1) = x(n) - 0.05*sin(y(n)) + tan(3*y(n))
y(n+1) = y(n) - 0.05*sin(x(n)) + tan(3*x(n))
demm, demj (Mandelbrot, Julia fractals calculated and
colored using the "Distance Estimator" method
Bifurcation (see the Bifurcation section for details)
Lorenz, Lorenz3d Lorenz Attractor - orbits of differential
equation:
dx/dt = -a*x + a*y
dy/dt = b*x - y -z*x
dz/dt = -c*z + x*y
Solution generated by 1st order Taylor series:
xnew = x + (-a*x*dt) + (a*y*dt)
ynew = y + (b*x*dt) - (y*dt) - (z*x*dt)
znew = z + (-c*z*dt) + (x*y*dt)
(defaults: dt = .02, a = 5, b = 15, c = 1)
(Lorenz3D is the Lorenz Attractor with the
addition of 3D perspective transformations
as specified by the IFS <E>ditor's
transformation option)
Rossler3d Orbit is solution to differential equation:
dx/dt = -y -z
dy/dt = x + a*y
dz/dt = b + x*z - c*z
Solution via first order Taylor series:
xnew = x - y*dt - z*dt
ynew = y + x*dt + a*y*dt
znew = z + b*dt + x*z*dt - c*z*dt
Default params are dt= .04, a= .2, b= .2, c= 5.7
Henon Orbit generated by:
xnew = 1 + y - a*x*x
ynew = b*x
The default parameters are a=1.4 and b=.3.
Pickover Orbit generated by:
xnew = sin(a*y) - z*cos(b*x)
ynew = z*sin(c*x) - cos(d*y)
znew = sin(x)
Default params are: a=2.24, b=.43, c=-.65, d=-2.43
Gingerbreadman Orbit generated by:
xnew = 1 - y + |x|
ynew = x
Diffusion See diffusion type description
Julibrot Same as Mandel and Julia - see type description
Here is an *ATTEMPTED* explanation of what the inside=bof60 and inside=bof61
options do. This explanation is hereby dedicated to Adrian Mariano, who
badgered it out of us! For the *REAL* explanation, see "Beauty of Fractals",
page 62. Let p(z) be the function that is repeatedly iterated to generate a
fractal using the escape-time algorithm. For example, p(z) = z^2+c in the
case of a Julia set. Then let pk(z) be the result of iterating the function
p for k iterations. (The "k" should be shown as a superscript.) We could
also use the notation pkc(z) when the function p has a parameter c, as it
does in our example. Now hold your breath and get your thinking cap on:
Define a(c) = inf{|pck(0)|:k=1,2,3,...}. In English - a(c) is the greatest
lower bound of the images of zero of as many iterations as you like. Put
another way, a(c) is the closest to the origin any point in the orbit
starting with 0 gets. Then the index (c) is the value of k (the iteration)
when that closest point was achieved. Since there may be more than one,
index(c) is the least such. Got it? Good, because the "Beauty of Fractals"
explanation of this, is, ahhhh, *TERSE* ! Now for the punch line.
Inside=bof60 colors the lake alternating shades according to the level sets
of a(c). Each band represents solid areas of the fractal where the closest
value of the orbit to the origin is the same. Inside=bof61 show domains where
index(c) is constant. That is, areas where the iteration when the orbit
swooped closest to the origin has the same value. Well, folks, that's the
best we can do! Improved explanations will be accepted for the next edition!
The following trig identities are invaluable for coding fractals that
use complex-valued transcendental functions.
e^(x+iy) = (e^x)cos(y) + i(e^x)sin(y)
sin(x+iy) = sin(x)cosh(y) + icos(x)sinh(y)
cos(x+iy) = cos(x)cosh(y) - isin(x)sinh(y)
sinh(x+iy) = sinh(x)cos(y) + icosh(x)sin(y)
cosh(x+iy) = cosh(x)cos(y) + isinh(x)sin(y)
ln(x+iy) = (1/2)ln(x*x + y*y) + i(arctan(y/x) + 2kPi)
(k = 0, +-1, +-2, +-....)
sin(2x) sinh(2y)
tan(x+iy) = ------------------ + i------------------
cos(2x) + cosh(2y) cos(2x) + cosh(2y)
sinh(2x) sin(2y)
tanh(x+iy) = ------------------ + i------------------
cosh(2x) + cos(2y) cosh(2x) + cos(2y)
z^z = e^(log(z)*z)
log(x + iy) = 1/2(log(x*x + y*y) + i(arc_tan(y/x))
e^(x + iy) = (cosh(x) + sinh(x)) * (cos(y) + isin(y))
= e^x * (cos(y) + isin(y))
= (e^x * cos(y)) + i(e^x * sin(y))
APPENDIX B
STONE SOUP WITH PIXELS: THE AUTHORS
Once upon a time, somewhere in Eastern Europe, there was a great
famine. People jealously hoarded whatever food they could find, hiding
it even from their friends and neighbors. One day a peddler drove his
wagon into a village, sold a few of his wares, and began asking ques-
tions as if he planned to stay for the night.
[No! No! It was three Russian Soldiers! - Lee Crocker]
[Wait! I heard it was a Wandering Confessor! - Doug Quinn]
[Well *my* kids have a book that uses Russian Soldiers! - Bert]
[Look, who'se writing this documentation, anyway? - Monte]
[Ah, but who gets it *last* and gets to upload it? - Bert]
"There's not a bite to eat in the whole province," he was told. "Better
keep moving on."
"Oh, I have everything I need," he said. "In fact, I was thinking of
making some stone soup to share with all of you." He pulled an iron
cauldron from his wagon, filled it with water, and built a fire under
it. Then, with great ceremony, he drew an ordinary-looking stone from a
velvet bag and dropped it into the water.
By now, hearing the rumor of food, most of the villagers had come to
the square or watched from their windows. As the peddler sniffed the
"broth" and licked his lips in anticipation, hunger began to overcome
their skepticism.
"Ahh," the peddler said to himself rather loudly, "I do like a tasty
stone soup. Of course, stone soup with CABBAGE -- that's hard to beat."
Soon a villager approached hesitantly, holding a cabbage he'd retrieved
from its hiding place, and added it to the pot. "Capital!" cried the
peddler. "You know, I once had stone soup with cabbage and a bit of
salt beef as well, and it was fit for a king."
The village butcher managed to find some salt beef...and so it went,
through potatoes, onions, carrots, mushrooms, and so on, until there
was indeed a delicious meal for all. The villagers offered the peddler
a great deal of money for the magic stone, but he refused to sell and
traveled on the next day. And from that time on, long after the famine
had ended, they reminisced about the finest soup they'd ever had.
***
That's the way FRACTINT has grown, with quite a bit of magic, although
without the element of deception. (You don't have to deceive program-
mers to make them think that hours of painstaking, often frustrating
work is fun... they do it to themselves.)
It wouldn't have happened, of course, without Benoit Mandelbrot and the
explosion of interest in fractal graphics that has grown from his work
at IBM. Or without the example of other Mandelplotters for the PC. Or
without those wizards who first realized you could perform Mandelbrot
calculations using integer math (it wasn't us - we just recognize good
algorithms when we steal--uhh--see them). Or those graphics experts
who hang around the Compuserve PICS forum and keep adding video modes
to the program. Or...
A WORD ABOUT THE AUTHORS
FRACTINT is the result of a synergy between the main authors,
many contributors, and published sources. All three of the main
authors have had a hand in many aspects of the code. However
each author has certain areas of greater contribution and
creativity. Since there is not room in the help screen for the
contributions of the main authors, we list these here to
facilitate those who would like to communicate with us on
particular subjects.
Bert Tyler is the original author. He wrote the "blindingly
fast" 386-specific 32 bit integer math code and the original
video mode logic. More than any of the authors, he has
personally touched and massaged the entire source. His forte is
writing fast 80x86 assembler, his knowledge of a variety of video
hardware, and his skill at hacking up the code we send him!
Bert has a BA in mathematics from Cornell University. He has
been in programming since he got a job at the computer center in
his sophmore year at college - in other words, he hasn't done an
honest day's work in his life. He has been known to pass himself
off as a PC expert, a UNIX expert, a statistician, and even a
financial modeling expert. He is currently masquerading as an
independent PC consultant, supporting the PC-to-Mainframe
communications environment at NIH. If you sent mail from the
Internet to an NIH staffer on his 3+Mail system, it was probably
Bert's code that mangled it during the Internet-to-3+Mail
conversion. He also claims to support the MS-Kermit environment
at NIH. Fractint is Bert's first effort at building a graphics
program.
Tim Wegner contributed the original implementation of palette
animation, and is responsible for most of the 3D mechanisms. He
provided the main outlines of the "StandardFractal" engine and
data structures, and is accused by his cohorts of being "obsessed
with options". Tim is quite proud of having originally
integrated the 256 color super VGA modes in FRACTINT, especially
since he knows almost nothing about it!
Tim has BA and MA degrees in mathematics from Carleton College
and the University of California Berkeley. He worked for 7 years
overseas as a volunteer, doing things like working with Egyptian
villagers building water systems. Since returning to the US in
1982, he has written shuttle navigation software, a software
support environment prototype, and supported strategic
information planning, all at NASA's Johnson Space Center.
Mark Peterson invented the periodicity detection logic, several
original fractal types, transcendental function libraries,
alternate math implementations, the formula compiler, and the
"Juliabrot" intrinsic 3D fractals - in other words, most of the
truly original ideas in FRACTINT!
Mark's knowledge of higher mathematics and programing was
achieved almost entirely through self-study. Currently he works
as a real-time supervisor of the electrical transmission system
for Connecticut and Massachusetts. When not hard at work on
programming projects he relaxes with Karate and Judo.
Accessing the Authors
======================================
Communication between the authors for development of the next version
of FRACTINT takes place in COMART (Computer Art) Section 15 (Fractals)
of CompuServe (CIS). Access to this area is open to any and all
interested in computer generated fractals. Stop on by if you have
any questions or just want to take a peek at what's getting tossed
into the soup!
Also, you'll find many GIF image files generated by fellow Fractint
fans and many fractal programs as well in that forum's data library 15.
The following authors have agreed to the distribution of their address-
es. Usenet/Internet/Bitnet/Whatevernet users can reach CIS
users directly if they know the user ID (i.e., Bert Tyler can be
reached as 73477.433@compuserve.com).
Just remember that CIS charges by the minute, so it costs us a little
bit to read a message -- don't kill us with kindness. And don't send
all your mail to Bert -- spread it around a little!
Bert Tyler [73477,433] on CIS
Tyler Software btyler on BIX
124 Wooded Lane
Villanova, PA 19085
(215) 525-6355
Timothy Wegner [71320,675] on CIS
4714 Rockwood nmittiw@mwvm.mitre.org on Internet
Houston, TX 77004 twegner@mwunix.mitre.org on Internet
(713) 747-7543
Mark C. Peterson [70441,3353] on CIS
253 West St., H
Plantsville, CT 06479
(203) 276-9474 (voice)
Rob Beyer [71021,2074] on CIS
23 Briarwood Lane
Laguna Hills, CA, 92656
(714) 831-7665
(7-12pm PST & weekends)
Pieter Branderhorst [72611,2257] on CIS
Amthor Computer Consultants
3915 Bedford Rd.
Victoria, B.C., Canada V8N 4K6
(604) 477-1197
Lee Daniel Crocker [73407,2030] on CIS
1380 Jewett Avenue lcrocker on BIX
Pittsburg, CA 94565 ames!pacbell!sactoh0!siva!lee on Usenet
(408) 354-8001
Monte Davis [71450,3542] on CIS
31 Washington St
Brooklyn, NY 11201
(718) 625-4610
Richard Finegold [76701,153] on CIS
1414 179th Ave NE richg@blake.acs.washington.edu on InterNET
Bellevue, WA 98008 uw-beaver!blake!richg on UseNET
(206) 746-2694
David Guenther [70531,3525] on CIS
50 Rockview Drive
Irvine, CA 92715
Michael L. Kaufman [71610,431] on CIS
2247 Ridge Ave, #2K (also accessible via EXEC-PC bbs)
Evanston, IL, 60201
(708) 864-7916
Joe McLain [75066,1257] on CIS
McLain Imaging
2417 Venier
Costa Mesa, CA 92627
(714) 642-5219
Bob Montgomery [73357,3140] on CIS
(Author of VPIC)
132 Parsons Road
Longwood, Fl 32779
Marc Reinig [72410,77] on CIS
3415 Merrill Rd. mqr@sun.com!daver!cypress!pld on Usenet
Aptos, CA. 95003 abu on BIX
(408) 475-2132
Dean Souleles [75115,1671] on CIS
8840 Collett Ave.
Sepulveda, CA 91343
(818) 893-7558
Scott Taylor [72401,410] on CIS
1901 South County Road 23E
Berthoud, CO 80513
(303) 651-6692
Paul Varner [73237,441] on CIS
PO Box 930
Shepherdstown, WV 25443
(304) 876-2011
Phil Wilson [76247,3145] on CIS
410 State St., #55
Brooklyn, NY 11217
(718) 624-5272
APPENDIX C
REVISION HISTORY
Features first appearing in:
===========================
Version 12.0, 3/90
New SuperVGA Autodetecting and VESA Video modes (you tell us the
resolution you want, and we'll figure out how to do it)
New Full-Screen Entry for most prompting
New Fractal formula interpreter ('type=formula') - roll your own
fractals without using a "C" compiler!
New 'Julibrot' fractal type
Added floating point option to all remaining fractal types.
Real (funny glasses) 3D - Now with "real-time" lorenz3D!!
Non-Destructive <TAB> - Check out what your fractal parameters are
without stopping the generation of a fractal image
New Cross-Hair mode for changing individual palette colors (VGA only)
Zooming beyond the limits of Integer algorithms (with automatic
switchover to a floating-point algorithm when you zoom in "too far")
New 'inside=bof60', 'inside=bof61' ("Beauty of Fractals, Page nn") options
New starmap ('a' - for astrology? astronomy?) transformation option
Restrictions on the options available when using Expanded Memory
"Disk/RAM" video mode have been removed
And a lot of other nice little clean-up features that we've already
forgotten that we've added...
Added capability to create 3D projection images (just barely) for people
with 2 or 4 color video boards.
Version 11.0, 1/90
More fractal types
mandelsinh/lambdasinh mandelcosh/lambdacosh
mansinzsqrd/julsinzsqrd mansinexp/julsinexp
manzzprw/julzzpwr manzpower/julzpower
lorenz (from Rob Beyer) lorenz3d
complexnewton complexbasin
popcorn
Virtually every fractal type given an integer AND a floating point algorithm.
"Float=yes" option now determines whether integer or floating-point
algorithms are used for most fractal types
"F" command toggles the use of floating-point algorithms, flagged in
the <Tab> status display
8/16/32/../256-Way decomposition option (from Richard Finegold)
"Biomorph=", "bailout=", "symmetry=" and "askvideo=" options
"T(ransform)" option in the IFS editor lets you select 3D options (used
with the Lorenz3D fractal type)
The "T(ype)" command uses a new "Point-and-Shoot" method of selecting
fractal types rather than prompting you for a type name
Bug fixes to continuous-potential algorithm on integer fractals, GIF
encoder, and IFS editor
Version 10.0, 11/89
Barnsley IFS type (Rob Beyer)
Barnsley IFS3D type
MandelSine/Cos/Exp type
MandelLambda/MarksLambda/Unity type
BarnsleyM1/J1/M2/J2/M3/J3 type
Mandel4/Julia4 type
Sierpinski gasket type
Demm/Demj and bifurcation types (Phil Wilson), "test" is "mandel"
again
<I>nversion command for most fractal types
<Q>uaternary decomposition toggle and "DECOMP=" argument
<E>ditor for Barnsley IFS parameters
Command-line options for 3D parameters
Spherical 3D calculations 5x faster
3D now clips properly to screen edges and works at extreme
perspective
"RSEED=" argument for reproducible plasma clouds
Faster plasma clouds (by 40% on a 386)
Sensitivity to "continuous potential" algorithm for all types except
plasma and IFS
Palette-map <S>ave and Restore (<M>) commands
<L>ogarithmic and <N>ormal palette-mapping commands and arguments
Maxiter increased to 32,000 to support log palette maps
.MAP and .IFS files can now reside anywhere along the DOS path
Direct-video support for Hercules adapters (Dean Souleles)
Tandy 1000 160x200x16 mode (Tom Price)
320x400x256 register-compatible-VGA "tweaked" mode
ATI VGA Wonder 1024x768x16 direct-video mode (Mark Peterson)
1024x768x16 direct-video mode for all supported chipsets
Tseng 640x400x256 mode
"Roll-your-own" video mode 19
New video-table "hot-keys" eliminate need for enhanced keyboard to
access later entries
Version 9.3, 8/89
<P>rint command and "PRINTER=" argument (Matt Saucier)
8514/A video modes (Kyle Powell)
SSTOOLS.INI sensitivity and '@THISFILE' argument
Continuous-potential algorithm for Mandelbrot/Julia sets
Light source 3D option for all fractal types
"Distance estimator" M/J method (Phil Wilson) implemented as "test"
type
LambdaCosine and LambdaExponent types
Color cycling mode for 640x350x16 EGA adapters
Plasma clouds for 16-color and 4-color video modes
Improved TARGA support (Joe McLain)
CGA modes now use direct-video read/writes
Tandy 1000 320x200x16 and 640x200x4 modes (Tom Price)
TRIDENT chip-set super-VGA video modes (Lew Ramsey)
Direct-access video modes for TRIDENT, Chips & Technologies, and ATI
VGA WONDER adapters (John Bridges)... and, unlike version 9.1, they
WORK in version 9.3!)
"Zoom-out" (<Control><Enter>) command
<D>os command for shelling out
2/4/16-color Disk/RAM video mode capability and 2-color video modes
supporting full-page printer graphics
"INSIDE=-1" option (treated dynamically as "INSIDE=maxiter")
Improved <H>elp and sound routines (even a "SOUND=off" argument)
Turbo-C and TASM compatibility (really! Would we lie to you?)
Version 8.1, 6/89
<3>D restore-from-disk and 3D <O>verlay commands, "3D=" argument
Fast Newton algorithm including inversion option (Lee Crocker)
16-bit Mandelbrot/Julia logic for 386-class speed with non-386 PCs on
"large" images (Mark Peterson)
Restore now loads .GIF files (as plasma clouds)
TARGA video modes and color-map file options (Joe McLain)
30 new color-cycling palette options (<Shft><F1> to <Alt><F10>)
"Disk-video, RAM-video, EMS-video" modes
Lambda sets now use integer math (with 80386 speedups)
"WARN=yes" argument to prevent over-writing old .FRA files
Version 7.0, 4/89
Restore from disk (from prior save-to-disk using v. 7.0 or later)
New types: Newton, Lambda, Mandelfp, Juliafp, Plasma, Lambdasine
Many new color-cycling options (for VGA adapters only)
New periodicity logic (Mark Peterson)
Initial displays recognize (and use) symmetry
Solid-guessing option (now the default)
Context-sensitive <H>elp
Customizable video mode configuration file (FRACTINT.CFG)
"Batch mode" option
Improved super-VGA support (with direct video read/writes)
Non-standard 360 x 480 x 256 color mode on a STANDARD IBM VGA!
Version 6.0, 2/89
32-bit integer math emulated for non-386 processors; FRACT386 renamed
FRACTINT
More video modes
Version 5.1, 1/89
Save to disk
New! Improved! (and Incompatible!) optional arguments format
"Correct" initial image aspect ratio
More video modes
Version 4.0, 12/88
Mouse support (Mike Kaufman)
Dynamic iteration limits
Color cycling
Dual-pass mode
More video modes, including "tweaked" modes for IBM VGA and register-
compatible adapters
Version 3.1, 11/88
Julia sets
Version 2.1, 10/23/88 (the "debut" on CIS)
Video table
CPU type detector
Version 2.0, 10/10/88
Zoom and pan
Version 1.0, 9/88
The original, blindingly fast, 386-specific 32-bit integer algorithm
APPENDIX D
BIBLIOGRAPHY
BARNSLEY, Michael: "Fractals Everywhere", Academic Press, 1988.
DEWDNEY, A. K., "Computer Recreations" columns in "Scientific
American" -- 8/85, 7/87, 11/87, 12/88, 7/89.
FEDER, Jens: "Fractals", Plenum, 1988. Quite technical, with good coverage
of applications in fluid percolation, game theory, and other areas.
GLEICK, James: "Chaos: Making a New Science", Viking Press, 1987.
The best non-technical account of the revolution in our
understanding of dynamical systems and its connections with fractal
geometry.
MANDELBROT, Benoit: "The Fractal Geometry of Nature", W. H. Freeman &
Co., 1982.
An even more revised and expanded version of the 1977 work. A rich
and sometimes confusing stew of formal and informal mathematics,
the prehistory of fractal geometry, and everything else. Best taken
in small doses.
MANDELBROT, Benoit: "Fractals: Form, Chance, and Dimension", W. H.
Freeman & Co., 1977
A much revised translation of "Les objets fractals: forme, hasard,
et dimension," Flammarion, 1975.
PEITGEN, Heinz-Otto & RICHTER, Peter: "The Beauty of Fractals,"
Springer-Verlag, 1986.
THE coffee-table book of fractal images, knowledgeable on computer
graphics as well as the mathematics they portray.
PEITGEN, Heinz-Otto & SAUPE, Ditmar: "The Science of Fractal Images,"
Springer-Verlag, 1988.
A fantastic work, with a few nice pictures, but mostly filled
with *equations*!!!
APPENDIX E
OTHER FRACTAL PROGRAMS
(This section is new, and pathetically small because we added it at the
last minute. Please help us out, here...)
FDESIGN, by Doug Nelson (CIS ID 70431,3374) - a freeware IFS fractal
generator available from Compuserve in COMART Lib 15, and probably
on your local BBS. This program requires a VGA adapter and a Microsoft-
compatible mouse, but it generates IFS fractals in a *much* more
intuitive fashion than Fractint. It can also (beginning with version
3.0) save its IFS formulas in Fractint-style .IFS files.